Keys to the Oracle Cloud
第１２回：【CURRENT DATA編】
PaaSレイヤの実装③（アプリケーションのデプロイ）

大塚紳一郎, 2020年4月

著者紹介

大塚　紳一郎（おおつか しんいちろう）

2003年、株式会社野村総合研究所に新卒で入社。ミッションクリティカルシステムにおけるOracle Databaseの構築、運用、コンサルティングに関して15年以上の経験を持つ。毎年サンフランシスコで開催される世界最大のテクノロジーイベント「Oracle OpenWorld」を含む各種イベントでの講演多数。Autonomous DatabaseがGAされた年にOracle ACE Associateになれたことに運命を感じており、Oracleデータベース管理者の今後のロールモデルの構築に携わりたいと考え日々活動中。最新の登壇タイトルは「Boosting your career through Oracle Cloud Infrastructure 2018 Certified Architect Associate.」

 

  • NRI認定ITアーキテクト
  • Oracle ACE Associate
  • Oracle MASTER Platinum10g,11g,12c(Platinum of the year 2016 in Japan)
  • Oracle MASTER Cloud Oracle Database Cloud Service
  • Oracle MASTER Cloud Oracle Java Cloud Service
  • Oracle Cloud Infrastructure 2018 Certified Architect Associate
  • Oracle Database Cloud Service 2019 Operations Certified Associate
  • Oracle Autonomous Database Cloud 2019 Certified Specialist
o-aceassociate-otsuka-250px
o-acessociate-rgb-250px
  • これからの内容はOracle Cloud Infrastructure (以下OCI)のサービスを前提としたものです。
  • 検証時点(2019年3月末)のOCIのサービス内容に基づいて記載しているため、内容が一部異なる場合があります。
  • 最新の情報については公式Webサイト（https://www.oracle.com/jp/cloud/）をご確認頂きたく思います。
  • 本連載は私個人の理解に基づいており、事実と異なる可能性があることをご了承いただきたく思います。

こんにちは、NRIの大塚です。今回はCURRENT DATA領域の連載５回目です。

 

otsuka-key2oraclecloud9-img-01

 

テーマとするPaaSはOracle Container Engine for Kubernetes（OKE）です。
今回はOracle Container Engine for Kubernetes環境下に検証用のアプリケーションを稼働させ、障害試験を通じて「宣言的」と言われる挙動の確認をしていきたいと思います。

前回は下図のようにOKEにアクセスするところまで構築しました。

otsuka-key2oraclecloud12-img-01

 

今回はこのOracle Container Engine for Kubernetes環境を用いてアプリケーションを稼働させて、「宣言的」と言われる挙動を確認したいと思います。アプリケーション開発は本連材の主眼ではないので、割愛させて頂きます。80番ポートで通信する一般的なWebアプリケーションのDocker Image(コンテナイメージ)がDocker Hubに登録されていることを前提に、それをOracle Container Engine for Kubernetes環境に展開していく流れで稼働確認をしていきたいと思います。アプリケーションの準備についてはDocker Hubのサンプルや、日本オラクル様のドキュメントをご参照下さい。

otsuka-key2oraclecloud12-img-02

 

新しい登場人物が増えましたので説明します。 Docker Hub：ockerによって管理されるパブリックレジストリです。アプリケーションやサービス・コンテナの構築と配信を行います。ですのでDocker Hubではコンテナ化されたイメージを見つけたり、配布したり、変更の管理ができます。
Docker Hubの概要

OCI Registry：Oracle Cloudにおけるコンテナレジストリサービスです。Oracle Container Engine for KubernetesからDockerイメージをPullして使用することができます。
Oracle Cloud Infrastructureドキュメント～レジストリの概要～

実際の環境構成図は以下のようになります。

otsuka-key2oraclecloud12-img-03

 

今回は以下の4ステップで構築していきます。

  • Step1：K8sコントロールサーバへのDockerクライアントのセットアップ
  • Step2：K8sコントロールサーバからOCI RegistryへDocker ImageをPush
    　　　　稼働確認を行うサンプルアプリケーションのDocker ImageをPull
    　　　　PullしたDocker Imageにタグをつける
    　　　　OCI RegistryにDocker ImageをPush
  • Step3：Oracle Container Engine for Kubernetes環境下で
    　　　　稼働確認を行うサンプルアプリケーションをロードバランサ経由で稼働させる
  • Step4：意図的に障害を発生させて、Oracle Container Engine for Kubernetes環境下の挙動を確認する

それでは、さっそくはじめたいと思います。

 

1. K8sコントロールサーバへのDockerクライアントのセットアップ

このセクションでは下図[Step1]を行います。

otsuka-key2oraclecloud12-img-04

 

まずK8sコントロールサーバにログインします（詳細は前回分を参照してください）

 



[opc@プロキシサーバのhostname 鍵ファイル置き場]$ ssh -i myrsa opc@ K8sコントロールサーバのPrivateIPアドレス
[opc@K8sコントロールサーバのhostname ~]$

 

Dockerクライアントのセットアップ手順は以下となります。
（後述する実行ログと見比べて実行してみてください）

●ファイアウォールをオフにする



sudo systemctl disable firewalld
    sudo systemctl is-enabled firewalld
    →「disabled」が表示されることを確認してください
    sudo systemctl stop firewalld
    sudo systemctl status firewalld
    →「Active: inactive」と表示されることを確認してください

 

●SELinuxの停止



sudo vi /etc/selinux/config
    →修正前SELINUX=enforcing
    →修正後SELINUX=disabled

 

●swapの無効化



sudo vi /etc/rc.localへ追記
    -------------------------------
    /usr/bin/sudo /sbin/swapoff --all
    -------------------------------
    #権限変更
    sudo chmod +x /etc/rc.d/rc.local
    sudo swapoff --all
    free
    →下記に示すようにSwapが0になっていること。
            　　　total        used        free      shared  buff/cache   available
    ...
    Swap:             0           0           0

 

●Dockerのインストール



# タイムゾーンをUTCからJSTに変更
    sudo timedatectl set-timezone Asia/Tokyo
    date
    # Docker CEのインストール
    ## リポジトリのセットアップ
    ### 前提パッケージのインストール
    sudo su
    yum -y install yum-utils device-mapper-persistent-data lvm2
    ### dockerリポジトリの追加
    yum-config-manager \
     　  --add-repo \
       　https://download.docker.com/linux/centos/docker-ce.repo
    ## docker ceをインストール
    yum -y update && yum -y install docker-ce

 

●Dockerのデーモン化設定



## /etc/docker ディレクトリを作成
    sudo mkdir /etc/docker
    # dockerデーモンのセットアップ
    sudo cat > /etc/docker/daemon.json <<EOF
    {
    "exec-opts": ["native.cgroupdriver=systemd"],
    "log-driver": "json-file",
    "log-opts": {
        "max-size": "100m"
    },
    "storage-driver": "overlay2",
    "storage-opts": [
        "overlay2.override_kernel_check=true"
    ]
    }
    EOF
    sudo mkdir -p /etc/systemd/system/docker.service.d
    # dockerをリスタート
    sudo systemctl daemon-reload
    sudo systemctl restart docker
    sudo systemctl enable docker
    sudo systemctl status docker
    # OS再起動
    sudo shutdown -r now

 

以下に実行ログを記載いたします。



[opc@K8sコントロールサーバのhostname ~]$ sudo systemctl disable firewalld
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
[opc@K8sコントロールサーバのhostname ~]$ sudo systemctl is-enabled firewalld
disabled
[opc@K8sコントロールサーバのhostname ~]$ sudo systemctl stop firewalld
[opc@K8sコントロールサーバのhostname ~]$ sudo systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)
Dec 06 11:42:08 localhost.localdomain systemd[1]: Starting firewalld - dynami...
Dec 06 11:42:09 localhost.localdomain systemd[1]: Started firewalld - dynamic...
Dec 06 11:47:19 K8sコントロールサーバのhostname systemd[1]: Stopping firewalld - dynamic firewall .....
Dec 06 11:47:20 K8sコントロールサーバのhostname systemd[1]: Stopped firewalld - dynamic firewall d...n.
Hint: Some lines were ellipsized, use -l to show in full.
[opc@K8sコントロールサーバのhostname ~]$ 
[opc@K8sコントロールサーバのhostname ~]$ sudo vi /etc/selinux/config
～ファイルの編集を実施～
[opc@K8sコントロールサーバのhostname ~]$ sudo vi /etc/rc.local
～ファイルの編集を実施～
[opc@K8sコントロールサーバのhostname ~]$ sudo chmod +x /etc/rc.d/rc.local
[opc@K8sコントロールサーバのhostname ~]$ sudo swapoff --all
[opc@K8sコントロールサーバのhostname ~]$ free
              total        used        free      shared  buff/cache   available
Mem:       15116076      261812    14581348       16948      272916    14565832
Swap:             0           0           0
[opc@K8sコントロールサーバのhostname ~]$ sudo timedatectl set-timezone Asia/Tokyo
[opc@K8sコントロールサーバのhostname ~]$ date
Fri Dec  6 20:50:00 JST 2019
[opc@K8sコントロールサーバのhostname ~]$ sudo su
[root@K8sコントロールサーバのhostname opc]# yum -y install yum-utils device-mapper-persistent-data lvm2 2
Loaded plugins: langpacks, ulninfo
ol7_UEKR5                                                | 2.8 kB     00:00     
ol7_addons                                               | 2.8 kB     00:00
～中略～ 
Package yum-utils-1.1.31-52.0.1.el7.noarch already installed and latest version
Package device-mapper-persistent-data-0.8.5-1.el7.x86_64 already installed and latest version
Package 7:lvm2-2.02.185-2.0.1.el7_7.2.x86_64 already installed and latest version
Nothing to do
[root@K8sコントロールサーバのhostname opc]# yum-config-manager \
>     --add-repo \
>     https://download.docker.com/linux/centos/docker-ce.repo
Loaded plugins: langpacks
adding repo from: https://download.docker.com/linux/centos/docker-ce.repo
grabbing file https://download.docker.com/linux/centos/docker-ce.repo to /etc/yum.repos.d/docker-ce.repo
repo saved to /etc/yum.repos.d/docker-ce.repo
[root@K8sコントロールサーバのhostname opc]# yum -y update && yum -y install docker-ce
Loaded plugins: langpacks, ulninfo
docker-ce-stable                                         | 3.5 kB     00:00     
(1/2): docker-ce-stable/x86_64/updateinfo                  |   55 B   00:00     
(2/2): docker-ce-stable/x86_64/primary_db                  |  37 kB   00:00     
Resolving Dependencies
～中略～
Installed:
  docker-ce.x86_64 3:19.03.5-3.el7                                              
Dependency Installed:
  container-selinux.noarch 2:2.77-5.el7  containerd.io.x86_64 0:1.2.10-3.2.el7 
  docker-ce-cli.x86_64 1:19.03.5-3.el7  
Complete!
[root@K8sコントロールサーバのhostname opc]# mkdir /etc/docker
[root@K8sコントロールサーバのhostname opc]# 
[root@K8sコントロールサーバのhostname opc]# cat > /etc/docker/daemon.json <<EOF
> {
>   "exec-opts": ["native.cgroupdriver=systemd"],
>   "log-driver": "json-file",
>   "log-opts": {
>     "max-size": "100m"
>   },
>   "storage-driver": "overlay2",
>   "storage-opts": [
>     "overlay2.override_kernel_check=true"
>   ]
> }
> EOF
[root@K8sコントロールサーバのhostname opc]# mkdir -p /etc/systemd/system/docker.service.d
[root@K8sコントロールサーバのhostname opc]# systemctl daemon-reload
[root@K8sコントロールサーバのhostname opc]# systemctl restart docker
[root@K8sコントロールサーバのhostname opc]# systemctl enable docker
Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to  
/usr/lib/systemd/system/docker.service.
[root@K8sコントロールサーバのhostname opc]# systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-12-06 20:58:43 JST; 24s ago
     Docs: https://docs.docker.com
 Main PID: 1660 (dockerd)
   CGroup: /system.slice/docker.service
           mq1660 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/cont...
Dec 06 20:58:42 K8sコントロールサーバのhostname dockerd[1660]: time="2019-12-06T20:58:42.878558331+...c
～中略～
Dec 06 20:58:43 K8sコントロールサーバのhostname dockerd[1660]: time="2019-12-06T20:58:43.318448062+..."
Hint: Some lines were ellipsized, use -l to show in full.
[root@K8sコントロールサーバのhostname opc]# shutdown -r now

 

2．KubernetesコントロールサーバからOCI RegistryへDocker ImageをPush

このセクションでは下図[Step2]を行います。

otsuka-key2oraclecloud12-img-05

 

実際の環境構成図は以下のようになります。

otsuka-key2oraclecloud12-img-06

 

はじめに、これから作業を行うOKE-adminユーザーにOCI Registryを操作することができる権限を付与します。
Policyとして、リポジトリへのmanage権限を有するグループに所属していることが必要になります。
(ポリシー例：Allow group group-infra-admin to manage repos in tenancy)
Oracle Cloud管理コンソールへログインするところから作業を開始していきましょう。

Oracle Cloud管理コンソールへのログインはテナント管理者ユーザーとしてログインしてください。
（OKE-adminではありませんので、注意してください）
それではOracle Cloud管理コンソールへログインしてみましょう。URLは以下です。
https://www.oracle.com/jp/cloud/sign-in.html

otsuka-key2oraclecloud9-img-04

 

（注）２ステップ検証は以下の記事で実装しました。
「Keys to the Oracle Cloud第７回：【Tea break】 Oracle CloudにおけるMulti-Factor Authentication(多要素認証)の実装」
標準のログインシーケンスでは、２ステップ検証の画面には遷移しませんのでご注意ください。
上記の記事を参考に各自実装をお願いします。

Oracle Cloud管理コンソールへログインしたら、「ハンバーガーボタン」→「アイデンティティ」→「ポリシー」の順に押下します。

otsuka-key2oraclecloud12-img-08

 

リスト範囲のコンパートメントが「ルート」であることを確認の上、「ポリシーの作成」を押下してください。

otsuka-key2oraclecloud12-img-09

 

ポリシー・ステートメントを追加します。

otsuka-key2oraclecloud12-img-10

 

新しいステートメントとして
Allow group group-infra-admin to manage repos in tenancy
を追加します。

otsuka-key2oraclecloud12-img-11

 

新しいステートメントが追加できたので、サインアウトして、この後はOKE-adminユーザーで作業をします。

otsuka-key2oraclecloud12-img-12

 

OKE-adminユーザーでログインします。

otsuka-key2oraclecloud12-img-13

 

次にOCI Registryの操作で必要になる認証トークンを作成します。

otsuka-key2oraclecloud12-img-14

 

「認証トークン」を押下します。

otsuka-key2oraclecloud12-img-15

 

「トークンの作成」を押下します。

otsuka-key2oraclecloud12-img-16

 

「説明」に「connect to OKE」と入力し、「トークンの生成」を押下します。

otsuka-key2oraclecloud12-img-17

 

生成されたトークンを「コピー」を押下して、メモリにコピーし、メモ帳などに貼り付けして、忘れないようにして下さい。
一度閉じたら、分からなくなります。この認証トークンは後で使います。

otsuka-key2oraclecloud12-img-18

 

認証トークンの作成が完了いたしまた。

otsuka-key2oraclecloud12-img-19

 

K8sコントロールサーバからOCI RegistryへDocker ImageをPushするには以下手順が必要となります。

●Dockerログイン
　　　　sudo docker login <リージョンコード>.ocir.io
　　　　<リージョンコード>はASUBURNの場合、「iad」となります。

otsuka-key2oraclecloud12-img-20

 

　　　　docker loginの次に聞かれるのはUsernameとPasswordです。
　　　　Username: <テナント名>/<ユーザー名>
　　　　　　　　テナント名は各自のテナント名、ユーザー名はOKE-adminにしてください。
　　　　Password: Passwordは認証トークンを作成した時の値を入力してください。
　　　　　　　　メモ帳などに保存をお願いした値です。

●Docker HubからDockeイメージのPull
　　　　sudo docker pull <リポジトリ名>/<サンプルアプリ名>:latest
　　　　　　　　事前に準備したDockerイメージの最新版をPullします。

●PullしたDockerイメージの確認
　　　　sudo docker images

●Dockerイメージへタグを付与
　　　　sudo docker tag <リポジトリ名>/ <サンプルアプリ名>:latest <リージョンコード>.ocir.io/<テナント名>/<リポジトリ名>/<サンプルアプリ名>:<タグ>

<リポジトリ名>/ <サンプルアプリ名>:latest 先ほどdocker imagesコマンドで確認した値を用いてください。
<リージョンコード> docker login時に指定したリージョンコードと同じ値を用いてください。
<テナント名> 各自のテナント名を用いてください。
<リポジトリ名> OCI Registryに表示するリポジトリ名です。任意に決めてください。
<サンプルアプリ名> PullしたDockerイメージと同じ名前にしてください。
<タグ> version1.0

●OCI RegistryへのDockerイメージのPush
sudo docker push <リージョンコード>.ocir.io/<テナント名>/<リポジトリ名>/<サンプルアプリ名>:<タグ>

<リージョンコード>.ocir.io/<テナント名>/<リポジトリ名>/<サンプルアプリ名>:<タグ> タグ付け時と同じ値を用いてください。

●Oracle Cloud管理コンソールからGUIを用いてPushされたDockerイメージの確認を行います。

「ハンバーガーボタン」→「開発者サービス」→「レジストリ(OCIR)」を押下します。

otsuka-key2oraclecloud12-img-21

 

先ほどPushした「レジストリ／<サンプルアプリ名>」が表示されています。

otsuka-key2oraclecloud12-img-22

 

以下に実行ログを記載いたします。



[opc@K8sコントロールサーバのhostname ~]$ sudo docker login iad.ocir.io
Username: <テナント名>/OKE-admin
Password: 
Login Succeeded
[opc@K8sコントロールサーバのhostname ~]$sudo docker pull <リポジトリ名>/<サンプルアプリ名>:latest 
latest: Pulling from <リポジトリ名>/<サンプルアプリ名>
898c46f3b1a1: Pulling fs layer 
63366dfa0a50: Pulling fs layer 
041d4cd74a92: Pulling fs layer
～中略～
Status: Downloaded newer image for <リポジトリ名>/<サンプルアプリ名>:latest
docker.io/<リポジトリ名>/<サンプルアプリ名>:latest
[opc@K8sコントロールサーバのhostname ~]$ 
[opc@K8sコントロールサーバのhostname ~]$ sudo docker images
REPOSITORY                  TAG                 IMAGE ID            CREATED
<リポジトリ名>/ <サンプルアプリ名>   latest               exxxxxxxxxx8         6 months ago
[opc@K8sコントロールサーバのhostname ~]$ sudo docker tag <リポジトリ名>/<サンプルアプリ名>:latest iad.ocir.io/<テナント名>/<リポジトリ名>/<サンプルアプリ名>:version1.0
[opc@K8sコントロールサーバのhostname ~]$ 
 [opc@K8sコントロールサーバのhostname ~]$ sudo docker push iad.ocir.io/<テナント名>/<リポジトリ名>/<サンプルアプリ名>:version1.0
The push refers to repository [iad.ocir.io/<テナント名>/<リポジトリ名>/<サンプルアプリ名>]
6fbfc52ea0a2: Preparing 
527186c11e8f: Preparing 
9cb55fd639dd: Preparing
～中略～
Pushing  XX.07MB 762d8e1a6054: Pushing   YY.2MB762d8e1a6054: Pushing
Pushed version1.0: digest: sha256: size: XXXX
[opc@K8sコントロールサーバのhostname ~]$

3．Oracle Container Engine for Kubernetes環境下で稼働確認を行うサンプルアプリケーションをロードバランサ経由で稼働させる

このセクションでは下図[Step3]を行います。

otsuka-key2oraclecloud12-img-23

 

実際の環境構成図は以下のようになります。

otsuka-key2oraclecloud12-img-24

 

以下の手順でOracle Container Engine for Kubernetes環境下で稼働確認を行うサンプルアプリケーションを稼働させます。

●Dockerレジストリ・シークレットの作成(OCI Registryからpullするための資格証明)br ※初回に1度だけ実行する手順です

sudo kubectl create secret docker-registry <シークレット名> --docker-server=<リージョンコード>.ocir.io --docker-username='<テナント名>/<ユーザー名>' --docker-password='<認証トークン>'

<シークレット名> 任意の文字列（今回はmy1stsecret）
<リージョンコード> docker login時に指定したリージョンコードと同じ値を用いてください（今回はiad）
<テナント名> 各自のテナント名を用いてください
<ユーザー名> OKE-admin
<認証トークン> 作成済みの認証トークンの値

●Dockerレジストリ・シークレットが作成されたことを確認
kubectl get secrets

●PodのManifestを作成
Podは、Kubernetesで作成および管理できるデプロイ可能な最小のコンピューティング単位です。
通常Podは１つのアプリケーションまたは１つの稼働できる単位モジュールです。
ロードバランサ経由でサンプルアプリケーションを稼働させます。

otsuka-key2oraclecloud12-img-25

 

●Oracle Container Engine for Kubernetes環境下で稼働確認を行うサンプルアプリケーションを稼働させる
kubectl apply -f /home/opc/My1stApp.yaml

●稼働状況の確認
kubectl get pod,service

以下に実行ログを記載いたします。 



[opc@K8sコントロールサーバのhostname ~]$ kubectl create secret docker-registry <シークレット名> --docker-server=<リージョンコード>.ocir.io --docker-username='<テナント名>/<ユーザー名>' --docker-password='<認証トークン>'
secret/my1stsecret created

[opc@K8sコントロールサーバのhostname ~]$ kubectl get secrets
NAME                  TYPE                                  DATA   AGE
default-token-5zq2m   kubernetes.io/service-account-token   3      72d
my1stsecret            kubernetes.io/dockerconfigjson        1      5m4s

[opc@K8sコントロールサーバのhostname ~]$ pwd
/home/opc

[opc@K8sコントロールサーバのhostname ~]$ vi My1stApp.yaml 
～yamlファイルを作成～

[opc@K8sコントロールサーバのhostname ~]$ kubectl apply -f /home/opc/My1stApp.yaml
deployment.apps/<サンプルアプリ名>-deployment created
service/<サンプルアプリ名>-service created

[opc@K8sコントロールサーバのhostname ~]$ kubectl get pod,service
NAME                                                 READY   STATUS              RESTARTS   AGE
pod/<サンプルアプリ名>-deployment-68c45f7486-hlpc5   0/1     ContainerCreating   0          9s
pod/<サンプルアプリ名>-deployment-68c45f7486-nzcld   0/1     ContainerCreating   0          9s
pod/<サンプルアプリ名>-deployment-68c45f7486-z8xpj   0/1     ContainerCreating   0          9s

NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)     AGE
service/<サンプルアプリ名>-service   LoadBalancer   XXX.YYY.ZZZ.159   <pending>     80:31598/TCP   9s
service/kubernetes                   ClusterIP    AAA.BBB.CCC.1       <none>        443/TCP        72d

[opc@K8sコントロールサーバのhostname ~]$ kubectl get pod,service
NAME                                                 READY   STATUS    RESTARTS   AGE
pod/<サンプルアプリ名>-deployment-68c45f7486-hlpc5   1/1     Running   0          22s
pod/<サンプルアプリ名>-deployment-68c45f7486-nzcld   1/1     Running   0          22s
pod/<サンプルアプリ名>-deployment-68c45f7486-z8xpj   1/1     Running   0          22s

NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)     AGE
service/<サンプルアプリ名>-service   LoadBalancer   XXX.YYY.ZZZ.159   <pending>     80:31598/TCP   22s
service/kubernetes                   ClusterIP     AAA.BBB.CCC.1       <none>        443/TCP        72d

[opc@K8sコントロールサーバのhostname ~]$ kubectl get pod,service
NAME                                                 READY   STATUS    RESTARTS   AGE
pod/<サンプルアプリ名>-deployment-68c45f7486-hlpc5   1/1     Running   0          33s
pod/<サンプルアプリ名>-deployment-68c45f7486-nzcld   1/1     Running   0          33s
pod/<サンプルアプリ名>-deployment-68c45f7486-z8xpj   1/1     Running   0          33s

NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)    AGE
service/<サンプルアプリ名>-service   LoadBalancer  XXX.YYY.ZZZ.159   DDD.EEE.FFF.187   80:31598/TCP   33s
service/kubernetes                   ClusterIP   AAA.BBB.CCC.1       <none>           443/TCP        72d

何が起こったのか、実際のログを見ていきたいと思います。
kubectl apply -f /home/opc/My1stApp.yaml
により、アプリのデプロイと、サービスがcreatedされます。

kubectl get pod,service
の結果から、3つのPodのSTATUSがContainerCreating→Runningというように準備されていく状況が分かります。

NAME STATUS →STATUS
pod/<サンプルアプリ名>-deployment-68c45f7486-hlpc5 ContainerCreating →Running
pod/<サンプルアプリ名>-deployment-68c45f7486-nzcld ContainerCreating →Running
pod/<サンプルアプリ名>-deployment-68c45f7486-z8xpj ContainerCreating →Running

kubectl get pod,service
の結果は、ロードバランサ経由のアプリケーションサービスの準備状況も示しています。

NAME EXTERNAL-IP →EXTERNAL-IP
service/<サンプルアプリ名>-service <pending> →DDD.EEE.FFF.187

このように、外部からアクセスするためのIPアドレスが用意されます。
FirefoxなどのWebブラウザに
http:// DDD.EEE.FFF.187
と、URLの入力を行うと、アプリケーションの画面が表示されます（注：URLはアプリごとに変わります）
アプリケーションへのアクセスはロードバランサ経由となっており、ロードバランサが準備されていく様子をOracle Cloudの管理コンソールで見ていきたいと思います。

otsuka-key2oraclecloud12-img-26

 

kubectl apply -f /home/opc/My1stApp.yaml
実行前のOKEコンパートメント内のロードバランサの状況です。何も存在しないことが分かります。

otsuka-key2oraclecloud12-img-27

 

kubectl apply -f /home/opc/My1stApp.yaml
を実行し
deployment.apps/<サンプルアプリ名>-deployment created
service/<サンプルアプリ名>-service created
の、ようにservice createdとなると、以下のようにOKEコンパートメント内のロードバランサの生成が自動で開始されます。

otsuka-key2oraclecloud12-img-28

 

しばらくすると、状態が「アクティブ」となり、ロードバランサが作成されたことがわかります。

otsuka-key2oraclecloud12-img-29

 

作成されたロードバランサは
・仮想クラウド・ネットワーク：OKE
・サブネット（1/2）：LB-1
・サブネット（2/2）：LB-2
と、なっており、Oracle Container Engine for Kubernetesをプロビジョニングした時に指定した値が用いられていることが分かります。

otsuka-key2oraclecloud12-img-30

 

ロードバランサは2つのサブネットで生成されており、「リスナー」が用意されていることが分かります。

otsuka-key2oraclecloud12-img-31.png

 

そしてワーカー・ノードがバックエンド・セットになります。見ていきたいと思います。

otsuka-key2oraclecloud12-img-32

 

予想どおり、Oracle Container Engine for Kubernetesをプロビジョニングした時に指定した３台のワーカー・ノードがバックエンドになっております。

otsuka-key2oraclecloud12-img-33

 

実際の環境構成図は以下のようになります。

otsuka-key2oraclecloud12-img-34

 

次にPodがどのように配置されているか確認していきたいと思います。以下の手順で確認します。

●Podの名前を確認
kubectl get pods

●ワーカー・ノードのIPアドレスを確認
kubectl get node

●各ワーカー・ノードの詳細を確認
kubectl describe node <前述のkubectl get nodeで確認したワーカー・ノードのIPアドレス>
この結果を用いてワーカー・ノードとPodを紐付ける

以下に実行ログを記載いたします。 



[opc@K8sコントロールサーバのhostname ~]$ kubectl get pods
NAME              　　　　                         READY   STATUS    RESTARTS   AGE
<サンプルアプリ名>-deployment-68c45f7486-hlpc5   1/1       Running    0          22m
<サンプルアプリ名>-deployment-68c45f7486-nzcld   1/1       Running    0          22m
<サンプルアプリ名>-deployment-68c45f7486-z8xpj   1/1       Running    0          22m

[opc@K8sコントロールサーバのhostname ~]$ kubectl get node
NAME           STATUS   ROLES   AGE   VERSION
KKK.JJJ.21.2    Ready     node     72d   v1.13.5
KKK.JJJ.22.3    Ready     node     72d   v1.13.5
KKK.JJJ.23.2    Ready     node     72d   v1.13.5

[opc@K8sコントロールサーバのhostname ~]$ kubectl describe node KKK.JJJ.21.2
Name:               KKK.JJJ.21.2
Roles:                node
Namespace 　Name                              　　　CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
---------      ----                                      　　　  ------------  ----------  ---------------  -------------      ---
default     <サンプルアプリ名>-deployment-68c45f7486-nzcld    0 (0%)   0 (0%)      0 (0%)        0 (0%)          20m
～以下略～

[opc@K8sコントロールサーバのhostname ~]$ kubectl describe node KKK.JJJ.22.3
Name:               KKK.JJJ.22.3
Roles:                node
～中略～
Namespace  Name                               　　　CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
---------      ----                                      　　　  ------------  ----------  ---------------  -------------      ---
  default    <サンプルアプリ名>-deployment-68c45f7486-z8xpj    0 (0%)   0 (0%)      0 (0%)        0 (0%)         25m
～以下略～

[opc@K8sコントロールサーバのhostname ~]$ kubectl describe node KKK.JJJ.23.2
Name:               KKK.JJJ.23.2
Roles:                node
～中略～
Namespace  Name                                　　　CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
---------  　　　----                                      　　    ------------  ----------  ---------------  -------------       ---
default    　　<サンプルアプリ名>-deployment-68c45f7486-hlpc5    0 (0%)     0 (0%)      0 (0%)        0 (0%)        27m
～以下略～
[opc@K8sコントロールサーバのhostname ~]$

以上より以下のような関係となっています。

ワーカー・ノード Pod
KKK.JJJ.21.2 <サンプルアプリ名>-deployment-68c45f7486-nzcld
KKK.JJJ.22.3 <サンプルアプリ名>-deployment-68c45f7486-z8xpj
KKK.JJJ.23.2 <サンプルアプリ名>-deployment-68c45f7486-hlpc5

そして、ワーカー・ノードの詳細情報は、Oracle Cloudの管理コンソールで確認します。
コンパートメントが「OKE」であることを確認の上、インスタンスの一覧を表示します。
可用性ドメインが「-AD1」であるインスタンス名を押下してください。

otsuka-key2oraclecloud12-img-35

 

ワーカー・ノードのIPアドレスと稼働している可用性ドメインを紐づけることができます。

otsuka-key2oraclecloud12-img-36

以上より可用性ドメインまで含めて以下のような関係となっています。

可用性ドメイン ワーカー・ノード Pod
ASHBURNのAD-1 KKK.JJJ.21.2 <サンプルアプリ名>-deployment-68c45f7486-nzcld
ASHBURNのAD-2 KKK.JJJ.22.3 <サンプルアプリ名>-deployment-68c45f7486-z8xpj
ASHBURNのAD-3 KKK.JJJ.23.2 <サンプルアプリ名>-deployment-68c45f7486-hlpc5

実際の環境構成図は以下のようになります。

otsuka-key2oraclecloud12-img-37

 

無事Oracle Container Engine for Kubernetes環境下に検証用のアプリケーションを稼働させることができました。障害試験を通じて「宣言的」と言われる挙動の確認をしていきたいと思います。

4．意図的に障害を発生させて、Oracle Container Engine for Kubernetes環境下の挙動を確認する

●稼働中のPodを停止させます
kubectl delete pod <停止させたいPodのNAME> 



[opc@K8sコントロールサーバのhostname ~]$ kubectl get pods
NAME                                          READY   STATUS    RESTARTS   AGE
<サンプルアプリ名>-deployment-68c45f7486-hlpc5    1/1      Running    0           59m
<サンプルアプリ名>-deployment-68c45f7486-nzcld    1/1      Running    0           59m
<サンプルアプリ名>-deployment-68c45f7486-z8xpj    1/1      Running    0           59m

[opc@K8sコントロールサーバのhostname ~]$ kubectl delete pod <サンプルアプリ名>-deployment-68c45f7486-hlpc5

pod "<サンプルアプリ名>-deployment-68c45f7486-hlpc5" deleted

[opc@K8sコントロールサーバのhostname ~]$ kubectl get pods
NAME                                           READY   STATUS    RESTARTS   AGE
<サンプルアプリ名>-deployment-68c45f7486-59b88   1/1       Running    0           16s
<サンプルアプリ名>-deployment-68c45f7486-nzcld    1/1       Running    0           60m
<サンプルアプリ名>-deployment-68c45f7486-z8xpj    1/1       Running    0           60m

[opc@K8sコントロールサーバのhostname ~]$

すこし前の手順を思い出してください。
/home/opc/My1stApp.yaml
において「replicas: 3」と、宣言しているので、kubectl delete podでPodを１つ停止させても、すぐに全Podの数が３になるようにOKEが調整します(ログから、別名のPodで起動していることが分かります)。実際の動きは以下のようになります。

otsuka-key2oraclecloud12-img-38

Podの状態遷移をまとめます。

ワーカー・ノード PodのSTATUS PodのSTATUS
KKK.JJJ.21.2 <サンプルアプリ名>-deployment-68c45f7486-nzcld →Running
KKK.JJJ.22.3 <サンプルアプリ名>-deployment-68c45f7486-z8xpj →Running
KKK.JJJ.23.2 <サンプルアプリ名>-deployment-68c45f7486-hlpc5 →delete
- <サンプルアプリ名>-deployment-68c45f7486-59b88

長くなってきましたので、今回はここまでとしたいと思います。次回は、さらに障害試験を行い、それを通じてOracle Container Engine for Kubernetesの動きを確認し、CURRENT DATA編の第６回目になりますので、まとめを行いたいと思います。読んで頂き、ありがとうございました。

※Docker Hubの概要
http://docs.docker.jp/docker-hub/overview.html

※Oracle Cloud Infrastructureドキュメント～レジストリの概要～
https://docs.oracle.com/cd/E97706_01/Content/Registry/Concepts/registryoverview.htm


※Docker CLIを使用したイメージのプッシュ
https://docs.oracle.com/cd/E97706_01/Content/Registry/Tasks/registrypushingimagesusingthedockercli.htm

※Kubernetesデプロイメント中にレジストリからイメージをプル
https://docs.oracle.com/cd/E97706_01/Content/Registry/Tasks/registrypullingimagesfromocir.htm

※認証トークンの取得
https://docs.oracle.com/cd/E97706_01/Content/Registry/Tasks/registrygettingauthtoken.htm

※kubectlを使用したクラスタへのアクセス
https://docs.oracle.com/cd/E97706_01/Content/ContEng/Tasks/contengaccessingclusterkubectl.htm

※クラスタ・ノード間のトラフィックを分散するロード・バランサの作成
https://docs.oracle.com/cd/E97706_01/Content/ContEng/Tasks/contengcreatingloadbalancer.htm

Keys to the Oracle Cloud indexページ▶▶