このドキュメントで説明するソフトウェアは、サポートされなくなったか、Extended Support期間中です。
現在サポートされているリリースにアップグレードすることをお薦めします。

第4章 Kubernetesの管理および構成

目次

この章では、Kubernetesデプロイメントを構成および管理する方法について説明します。

4.1 Kubernetesとiptablesのルール

Kubernetesはiptablesを使用して多くのネットワーキングおよびポート転送のルールを処理します。競合するiptablesルールが作成される可能性のあるサービスは慎重に使用してください。ルールを確認するには、ルール・セットをSTDOUTにダンプするiptables-saveを実行します。

NodePortまたはLoadBalancingサービス・タイプを使用してアプリケーション・サービスを外部に公開する場合は、iptablesルール・セットでトラフィック転送を有効にする必要があります。アプリケーションを実行中のポッドで使用されているネットワークの外部からサービスにアクセスできない場合は、iptablesルール・セットに次のようなルールが含まれていないことを確認してください。 

:FORWARD DROP [0:0]

すべての転送トラフィックをドロップするルールがある場合は、次を実行する必要があります。 

# iptables -P FORWARD ACCEPT

iptablesをfirewalldではなくサービスとして実行している場合は、現在のiptables構成を保存して、再起動後も保持されるようにできます。このためには、次のコマンドを実行します。 

# iptables-save > /etc/sysconfig/iptables

これが機能するには、iptables-servicesパッケージがインストールされている必要があります。デフォルトのfirewalldサービスを使用することをお薦めします。これにより、より一貫性のあるエクスペリエンスが提供され、既存のルールをフラッシュしたりファイアウォールをリロードすることなく、ファイアウォール構成を変更できます。

ポッド間で直接通信する必要があるアプリケーションを実行中のノードとIP対応のアプリケーションを実行中のノードでは、デフォルトのfirewalldマスカレード・ルールをバイパスするために、追加のカスタムiptables構成が必要になる場合があります。たとえば、IPアドレス192.0.2.15でサーバー・アプリケーションを実行中のノード、およびIPアドレス192.0.2.16でクライアント・アプリケーションを実行中のノードで、次の2つのiptablesルールを設定すると、これらのノード間の直接通信が可能になります。 

# iptables -t nat -I POST_public_allow -s 192.0.2.15/32 -d 192.0.2.16/32 -j RETURN
# iptables -t nat -I POST_public_allow -s 192.0.2.16/32 -d 192.0.2.15/32 -j RETURN

4.2 プロキシ・サーバーでのKubernetesの使用方法

Docker HubやOracle Container Registryなどのインターネット・サービスにアクセスするようにプロキシ・サーバーが構成されている環境では、Kubernetesをインストールして正しく実行するために、いくつかの構成ステップを実行する必要があります。

  1. クラスタ内の各ノードのDockerエンジンの起動構成が、プロキシ・サーバーを使用するように構成されていることを確認します。たとえば、/etc/systemd/system/docker.service.d/http-proxy.confに、次の内容を含むsystemdサービス・ドロップイン・ファイルを作成します。 

    [Service]
Environment="HTTP_PROXY=http://proxy.example.com:80/"
Environment="HTTPS_PROXY=https://proxy.example.com:443/"

    http://proxy.example.com:80/をHTTPプロキシ・サービスのURLに置き換えます。HTTPSプロキシがあり、これも指定している場合は、https://proxy.example.com:443/をこのサービスのURLおよびポートに置き換えます。Docker systemdサービス構成を変更した場合は、次のコマンドを実行します。 

    # systemctl daemon-reload; systemctl restart docker

  2. クラスタ内の任意のノードで他のコマンドを実行できるように、http_proxyまたはhttps_proxy環境変数を設定することが必要になる場合があります。次に例を示します。 

    # export http_proxy="http://proxy.example.com:80/"
# export https_proxy="https://proxy.example.com:443/"

  3. ローカル・ホストおよびクラスタ内のすべてのノードIPのプロキシ構成を無効にします。 

    # export no_proxy="127.0.0.1, 192.0.2.10, 192.0.2.11, 192.0.2.12"

デプロイメントが正常に機能するには、これらのステップで十分です。ホストでの構成を必要とせず、内部ネットワーク・リクエストを無視する透過プロキシを使用すると、構成の複雑さを軽減でき、予期しない動作を回避するために役立ちます。

4.3 クラスタのバックアップおよびリストア

4.3.1 単一マスター・クラスタ

kubeadm-setup.shスクリプトを使用すると、クラスタのバックアップおよびリストア機能が有効になり、クラスタ内のマスター・ノードの障害からKubernetesデプロイメントを簡単に保護できます。クラスタのステータスおよび構成データは、クラスタ状態ストア(etcdとも呼ばれる)に格納されます。

バックアップおよびリストアのプロセスが正常に機能するには、いくつかの基本的な要件があります。

  • リストアするマスター・ノードのホスト名とIPアドレスは、バックアップされたマスター・ノードのホスト名とIPアドレスと一致する必要があります。リストアの通常のユースケースはシステム障害の後であるため、リストア・プロセスでは、マスター・ノードのシステムがDockerエンジンおよびKubernetesパッケージのフレッシュ・インストールと一致していることが想定されます。

  • マスター・ノードに必要なワークロードやコンテナ以外は実行できないように、マスター・ノードを汚染する必要があります。これは、kubeadm-setup.shスクリプトを使用して環境を設定した場合のデフォルト構成です。バックアップ・プロセスでは、Kubernetesクラスタの管理に固有のコンテナ以外のマスター・ノードで実行中のコンテナはバックアップされません。

  • backupコマンドは、マスター・ノードで実行する必要があります。

  • バックアップ・プロセス前にマスター・ノードに適用されたすべてのDockerエンジン構成は、リストア操作を実行するノードで、手動によりレプリケートする必要があります。リストア操作を実行する前に、Dockerストレージ・ドライバおよびプロキシの設定を手動で構成することが必要になる場合があります。

  • backupコマンドにより、指定されたバックアップの場所で100 MBの最小ディスク領域をチェックします。領域が使用可能でない場合、backupコマンドはエラーで終了します。

  • リストアは、同じバージョンのKubernetesを実行中のKubernetesクラスタのバックアップ・ファイルを使用する場合にのみ、正しく機能します。Kubernetes 1.8.4ツールを使用して、Kubernetes 1.7.4クラスタのバックアップ・ファイルをリストアすることはできません。

backupコマンドでは、バックアップ・プロセス中にクラスタを停止する必要があります。ワーカー・ノードでのコンテナ構成の実行は、バックアップ・プロセス中に影響を受けません。次のステップでは、マスター・ノードのバックアップ・ファイルを作成する方法について説明します。

クラスタの構成および状態のバックアップ

  1. クラスタを停止します。

    クラスタの構成および状態をバックアップするには、バックアップ・プロセス中に状態または構成が発生することがないように、クラスタを停止する必要があります。クラスタが停止している間、ワーカー・ノードはクラスタから独立して実行されるため、これらの各ノードでホストされているコンテナは引き続き機能します。クラスタを停止するには、マスター・ノードで次を実行します。 

    # kubeadm-setup.sh stop
Stopping kubelet now ...
Stopping containers now ...

  2. kubeadm-setup.sh backupを実行し、バックアップ・ファイルを格納する必要があるディレクトリを指定します。 

    # kubeadm-setup.sh backup /backups
Using container-registry.oracle.com/etcd:3.2.24
Checking if container-registry.oracle.com/etcd:3.2.24 is available
376ebb3701caa1e3733ef043d0105569de138f3e5f6faf74c354fa61cd04e02a 
/var/run/kubeadm/backup/etcd-backup-1544442719.tar
e8e528be930f2859a0d6c7b953cec4fab2465278376a59f8415a430e032b1e73 
/var/run/kubeadm/backup/k8s-master-0-1544442719.tar
Backup is successfully stored at /backups/master-backup-v1.12.5-2-1544442719.tar ...
You can restart your cluster now by doing: 
# kubeadm-setup.sh restart

    /backupsを、クラスタのバックアップ済データを格納するディレクトリへのパスに置き換えます。

    backupコマンドを実行するたびに、最新のバックアップ・ファイルを簡単にリストアできるように、タイムスタンプが付けられたtarファイルとして作成されます。バックアップ・ファイルには、リストア中にバックアップ・ファイルの有効性を検証するために使用されるsha256チェックサムも含まれます。backupコマンドにより、バックアップの終了時にクラスタを再起動するよう指示されます。

  3. クラスタを再起動します。 

    # kubeadm-setup.sh restart
Restarting containers now ...
Detected node is master ...
Checking if env is ready ...
Checking whether docker can pull busybox image ...
Checking access to container-registry.oracle.com ...
Trying to pull repository container-registry.oracle.com/pause ... 
3.1: Pulling from container-registry.oracle.com/pause
Digest: sha256:802ef89b9eb7e874a76e1cfd79ed990b63b0b84a05cfa09f0293379ac0261b49
Status: Image is up to date for container-registry.oracle.com/pause:3.1
Checking firewalld settings ...
Checking iptables default rule ...
Checking br_netfilter module ...
Checking sysctl variables ...
Restarting kubelet ...
Waiting for node to restart ...
....
Master node restarted. Complete synchronization between nodes may take a few minutes.

    クラスタが再起動するとき、クラスタの設定中に実行されたものと同様にチェックが実行され、クラスタが正常に機能しなくなる可能性のある環境変更が発生していないことが確認されます。クラスタを起動した後、クラスタ内のノードでステータスが報告され、クラスタが通常の動作に戻るまでに数分かかることがあります。

通常、リストア操作は新しくインストールされたホストで実行されますが、既存の設定構成が削除されている場合は、既存の設定で実行できます。リストア・プロセスでは、Dockerエンジンが元のマスター・ノードと同じ方法で構成されていることを前提としています。Dockerエンジンは、同じストレージ・ドライバを使用するように構成する必要があり、プロキシ構成が必要な場合は、次のステップで説明するとおり、リストア前に手動で設定する必要があります。

クラスタの構成および状態のリストア

  1. マスター・ホストで、最新のDockerおよびKubernetesのバージョンがインストールされていることと、マスター・ノードのIPアドレスとホスト名が、障害前に使用されていたIPアドレスとホスト名と一致していることを確認します。kubeadmパッケージでは、正しいバージョンのDockerエンジンを含む、必要なすべての依存関係が収集されます。 

    # yum install kubeadm kubectl kubelet

  2. kubeadm-setup.sh restoreコマンドを実行します。 

    # kubeadm-setup.sh restore /backups/master-backup-v1.12.5-2-1544442719.tar
Checking sha256sum of the backup files ...
/var/run/kubeadm/backup/etcd-backup-1544442719.tar: OK
/var/run/kubeadm/backup/k8s-master-0-1544442719.tar: OK
Restoring backup from /backups/master-backup-v1.12.5-2-1544442719.tar ...
Using 3.2.24
etcd cluster is healthy ...
Cleaning up etcd container ...
27148ae6765a546bf45d527d627e5344130fb453c4a532aa2f47c54946f2e665
27148ae6765a546bf45d527d627e5344130fb453c4a532aa2f47c54946f2e665
Restore successful ...
You can restart your cluster now by doing: 
# kubeadm-setup.sh restart

    /backups/master-backup-v1.12.5-2-1544442719.tarを、リストアするバックアップファイルへのフルパスに置き換えます。

  3. クラスタを再起動します。 

    # kubeadm-setup.sh restart
Restarting containers now ...
Detected node is master ...
Checking if env is ready ...
Checking whether docker can pull busybox image ...
Checking access to container-registry.oracle.com ...
Trying to pull repository container-registry.oracle.com/pause ... 
3.1: Pulling from container-registry.oracle.com/pause
Digest: sha256:802ef89b9eb7e874a76e1cfd79ed990b63b0b84a05cfa09f0293379ac0261b49
Status: Image is up to date for container-registry.oracle.com/pause:3.1
Checking firewalld settings ...
Checking iptables default rule ...
Checking br_netfilter module ...
Checking sysctl variables ...
Enabling kubelet ...
Created symlink from /etc/systemd/system/multi-user.target.wants/kubelet.service 
to /etc/systemd/system/kubelet.service.
Restarting kubelet ...
Waiting for node to restart ...
....+++++
Restarting pod kube-flannel-ds-glwgx
pod "kube-flannel-ds-glwgx" deleted
Restarting pod kube-flannel-ds-jz8sf
pod "kube-flannel-ds-jz8sf" deleted
Master node restarted. Complete synchronization between nodes may take a few minutes.

  4. Kubernetesのadmin.confファイルをホーム・ディレクトリにコピーします。 

    $ sudo cp /etc/kubernetes/admin.conf $HOME/

    ファイルの所有権を一般ユーザー・プロファイルと一致するように変更します。 

    $ sudo chown $(id -u):$(id -g) $HOME/admin.conf

    ファイルへのパスをKUBECONFIG環境変数にエクスポートします。 

    $ export KUBECONFIG=$HOME/admin.conf

    このファイルへのパスがこの環境変数に設定されていない場合は、kubectlコマンドを使用できません。以降のログインごとにKUBECONFIG変数を忘れずにエクスポートし、kubectlおよびkubeadmコマンドで、正しいadmin.confファイルが使用されるようにしてください。そうしないと、再起動または新規ログイン後、これらのコマンドが予期したとおりに動作しないことがあります。たとえば、エクスポート行を.bashrcに追加します。 

    $ echo 'export KUBECONFIG=$HOME/admin.conf' >> $HOME/.bashrc

  5. クラスタが正しくリストアされていることを確認します。kubectlを使用して、クラスタ内のノードのステータスを確認し、既存のすべての構成を確認します。次に例を示します。 

    $ kubectl get nodes
NAME                  STATUS    ROLES   AGE       VERSION
master.example.com    Ready     master  1h        v1.12.5+2.1.1.el7
worker1.example.com   Ready     <none>  1h        v1.12.5+2.1.1.el7
worker2.example.com   Ready     <none>  1h        v1.12.5+2.1.1.el7

$ kubectl get pods
NAME                                READY     STATUS    RESTARTS   AGE
nginx-deployment-4234284026-g8g95   1/1       Running   0          10m
nginx-deployment-4234284026-k1h8w   1/1       Running   0          10m
nginx-deployment-4234284026-sbkqr   1/1       Running   0          10m

4.3.2 高可用性クラスタ

kubeadm-ha-setupツールを使用すると、クラスタのバックアップおよびリストア機能が有効になり、クラスタ内のマスター・ノードの障害からKubernetesデプロイメントを簡単に保護できます。クラスタのステータス、構成データおよびスナップショットは、クラスタ状態ストア(etcdとも呼ばれる)に格納されます。

バックアップおよびリストアのプロセスが正常に機能するには、いくつかの基本的な要件があります。

  • リストアするマスター・ノードのホスト名とIPアドレスは、バックアップされたマスター・ノードのホスト名とIPアドレスと一致する必要があります。リストアの通常のユースケースはシステム障害の後であるため、リストア・プロセスでは、各マスター・ノードのシステムが、DockerエンジンおよびKubernetesパッケージのフレッシュ・インストールと一致していることが想定されます。

  • リストアは、同じバージョンのKubernetesを実行中のKubernetes高可用性クラスタのバックアップを使用する場合にのみ、正しく機能します。Dockerエンジンのバージョンも一致する必要があります。

  • バックアップおよびリストアのフェーズ中にマスター・クラスタ内のすべてのノードにアクセス可能な、専用の共有記憶域ディレクトリが存在する必要があります。

  • kubeadm-ha-setupを使用するときは、常に、マスター・クラスタ内のすべてのノードにマスター・クラスタ内の他のすべてのノードに対するパスワードなしのキーベースの認証を使用してルート・アクセスできることが必要です。

全体リストアが必要となるのは、一定の停止時間にマスター・クラスタ内の複数のノードが含まれていた場合のみです。全体リストアでは、リストア・プロセスの期間中、マスター・ノードの可用性が中断されることに注意してください。

クラスタの構成および状態のバックアップ

  1. kubeadm-ha-setup backupを実行し、バックアップ・ファイルを格納する必要があるディレクトリを指定します。 

    # kubeadm-ha-setup backup /backups
Disaster Recovery
Reading configuration file /usr/local/share/kubeadm/run/kubeadm/ha.yaml ...
CreateSSH /root/.ssh/id_rsa root
Backup  /backup
Checking overall clusters health ...
Performing backup on 192.0.2.10
Performing backup on 192.0.2.11
Performing backup on 192.0.2.13
{"level":"info","msg":"created temporary db file","path":"/var/lib/etcd/etcd-snap.db.part"}
{"level":"info","msg":"fetching snapshot","endpoint":"127.0.0.1:2379"}
{"level":"info","msg":"fetched snapshot","endpoint":"127.0.0.1:2379","took":"110.033606ms"}
{"level":"info","msg":"saved","path":"/var/lib/etcd/etcd-snap.db"}
[Backup is stored at /backup/fulldir-1544115826/fullbackup-1544115827.tar]

    /backupsを、マスター・クラスタのバックアップ・データを格納するネットワーク共有ディレクトリへのパスに置き換えます。

    backupコマンドを実行するたびに、最新のバックアップ・ファイルを簡単にリストアできるように、タイムスタンプが付けられたtarファイルとして作成されます。バックアップ・ファイルには、リストア中にバックアップ・ファイルの有効性を検証するために使用されるsha256チェックサムも含まれます。backupコマンドにより、バックアップの終了時にクラスタを再起動するよう指示されます。

通常、リストア操作は新しくインストールされたホストで実行されますが、既存の設定構成が削除されている場合は、既存の設定で実行できます。

リストア・プロセスでは、マスター・クラスタ内の各ノードのIPアドレス構成が、バックアップされたデータの構成と一致することを前提としています。新しくインストールされた1つ以上のホストにリストアする場合は、IPアドレス指定が、置換するホストに割り当てられたアドレスと一致していることを確認します。

リストア・プロセスでは、Dockerエンジンが元のマスター・ノードと同じ方法で構成されていることを前提としています。Dockerエンジンは、同じストレージ・ドライバを使用するように構成する必要があり、プロキシ構成が必要な場合は、次のステップで説明するとおり、リストア前に手動で設定する必要があります。

注意

高可用性マスター・クラスタの全体リストアでは、リストア操作の期間中、サービスの可用性が中断されます

クラスタの構成および状態のリストア

  1. マスター・ホストで、最新のDockerおよびKubernetesのバージョンがインストールされていることと、マスター・ノードのIPアドレスとホスト名が、障害前に使用されていたIPアドレスとホスト名と一致していることを確認します。kubeadmパッケージでは、正しいバージョンのDockerエンジンを含む、必要なすべての依存関係が収集されます。 

    # yum install kubeadm kubectl kubelet kubeadm-ha-setup

  2. kubeadm-ha-setup restoreコマンドを実行します。 

    # kubeadm-ha-setup restore /backups/fulldir-1544115826/fullbackup-1544115827.tar
Disaster Recovery
Reading configuration file /usr/local/share/kubeadm/run/kubeadm/ha.yaml ...
CreateSSH /root/.ssh/id_rsa root
Restore  /share/fulldir-1544115826/fullbackup-1544115827.tar 
with binary /usr/bin/kubeadm-ha-setup
Checking etcd clusters health (this will take a few mins) ...
Cleaning up node 10.147.25.195
Cleaning up node 10.147.25.196
Cleaning up node 10.147.25.197
file to be restored from:  /share/fulldir-1544115826/backup-10.147.25.195-1544115826.tar
Configuring keepalived for HA ...
success
success
file to be restored from:  /share/fulldir-1544115826/backup-10.147.25.196-1544115826.tar
[INFO]  /usr/local/share/kubeadm/kubeadm-ha/etcd-extract.sh 
/share/fulldir-1544115826/fullbackup-1544115827.tar 10.147.25.196:22  retrying ...
file to be restored from:  /share/fulldir-1544115826/backup-10.147.25.197-1544115827.tar
[INFO]  /usr/bin/kubeadm-ha-setup etcd 
fullrestore 10.147.25.197 10.147.25.197:22  retrying ...
[COMPLETED] Restore completed, cluster(s) may take a few minutes to get backup!

    /backups/fulldir-1544115826/fullbackup-1544115827.tarを、リストアするバックアップファイルへのフルパスに置き換えます。バックアップ・ディレクトリおよびファイルは、リストア・プロセス中にクラスタ内のすべてのマスター・ノードからアクセスできる必要があることに注意してください。

    スクリプトにより、3つのマスター・ノードすべてが現在正常であることが検出された場合は、次のように続行を確認する必要があります。 

    [WARNING] All nodes are healthy !!! This will perform a FULL CLUSTER RESTORE
pressing [y] will restore cluster to the state stored 
in /share/fulldir-1544115826/fullbackup-1544115827.tar

    または、スクリプトにより、複数のマスター・ノードが使用不可であることが検出された場合は、クラスタ全体のリストアに進む前にプロンプトが表示されます。

  3. Kubernetesのadmin.confファイルをホーム・ディレクトリにコピーします。 

    $ sudo cp /etc/kubernetes/admin.conf $HOME/

    ファイルの所有権を一般ユーザー・プロファイルと一致するように変更します。 

    $ sudo chown $(id -u):$(id -g) $HOME/admin.conf

    ファイルへのパスをKUBECONFIG環境変数にエクスポートします。 

    $ export KUBECONFIG=$HOME/admin.conf

    このファイルへのパスがこの環境変数に設定されていない場合は、kubectlコマンドを使用できません。以降のログインごとにKUBECONFIG変数を忘れずにエクスポートし、kubectlおよびkubeadmコマンドで、正しいadmin.confファイルが使用されるようにしてください。そうしないと、再起動または新規ログイン後、これらのコマンドが予期したとおりに動作しないことがあります。たとえば、エクスポート行を.bashrcに追加します。 

    $ echo 'export KUBECONFIG=$HOME/admin.conf' >> $HOME/.bashrc

  4. クラスタが正しくリストアされていることを確認します。kubectlを使用して、クラスタ内のノードのステータスを確認し、既存のすべての構成を確認します。次に例を示します。 

    $ kubectl get nodes
NAME                  STATUS    ROLES   AGE      VERSION
master1.example.com   Ready     master  1h       v1.12.5+2.1.1.el7
master2.example.com   Ready     master  1h       v1.12.5+2.1.1.el7
master3.example.com   Ready     master  1h       v1.12.5+2.1.1.el7
worker2.example.com   Ready     <none>  1h       v1.12.5+2.1.1.el7
worker3.example.com   Ready     <none>  1h       v1.12.5+2.1.1.el7

4.4 Kubernetesダッシュボード

kubeadm-setup.shスクリプトまたはkubeadm-ha-setupユーティリティを使用してKubernetesクラスタにマスター・ノードをインストールすると、Kubernetesダッシュボード・コンテナが、kube-system名前空間の一部として作成されます。これにより、標準的なWebブラウザを使用してアクセス可能な、直感的なグラフィカル・ユーザー・インタフェースがKubernetesに提供されます。

Kubernetesダッシュボードの詳細は、Kubernetesのドキュメント(https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/)を参照してください。

ダッシュボードにアクセスするには、プロキシ・サービスを実行して、そのサービスを実行中のノード上のトラフィックが、ダッシュボード・アプリケーションを実行中の内部ポッドに到達できるようにします。これを行うには、kubectlプロキシ・サービスを実行します。 

$ kubectl proxy
Starting to serve on 127.0.0.1:8001

ダッシュボードは、プロキシが実行されている間、プロキシを実行中のノードで使用可能です。プロキシを終了するには、[Ctrl]+[C]を使用します。これはsystemdサービスとして実行でき、有効にすると、以降の再起動後に常に使用可能にできます。 

# systemctl start kubectl-proxy
# systemctl enable kubectl-proxy

このsystemdサービスを実行するには、/etc/kubernetes/admin.confが存在する必要があります。プロキシ・サービスに使用するポートを変更したり、他のプロキシ構成パラメータを追加する場合は、/etc/systemd/system/kubectl-proxy.service.d/10-kubectl-proxy.confでsystemdドロップイン・ファイルを編集することで構成できます。kubectlプロキシ・サービスに使用可能な構成オプションの詳細は、次を実行することで取得できます。 

$ kubectl proxy ‐‐help

ダッシュボードにアクセスするには、プロキシを実行中のノードでWebブラウザを開き、http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/loginに移動します。

ログインするには、トークンを使用した認証が必要です。詳細は、https://github.com/kubernetes/dashboard/tree/master/docs/user/access-controlを参照してください。この目的に固有のトークンを設定していない場合は、名前空間コントローラなどのサービス・アカウントに割り当てられたトークンを使用できます。次のコマンドを実行して、名前空間コントローラのトークン値を取得します。 

$ kubectl -n kube-system describe $(kubectl -n kube-system \
   get secret -n kube-system -o name | grep namespace) | grep token:
token:      eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2Nvd\
            W50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSI\
            sImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJuYW1lc3BhY2UtY29ud\
            HJvbGxlci10b2tlbi1zeHB3ayIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1h\
            Y2NvdW50Lm5hbWUiOiJuYW1lc3BhY2UtY29udHJvbGxlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFj\
            Y291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjM4OTk1MWIyLWJlNDYtMTFlNy04ZGY2LTA4MDAyNzY\
            wOTVkNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlLXN5c3RlbTpuYW1lc3BhY2UtY2\
            9udHJvbGxlciJ9.aL-9sRGic_b7XW2eOsDfxn9QCCobBSU41J1hMbT5D-Z86iahl1mQnV60zEKOg-45\
            5pLO4aW_RSETxxCp8zwaNkbwoUF1rbi17FMR_zfhj9sfNKzHYO1tjYf0lN452k7_oCkJ7HR2mzCHmw-\
            AygILeO0NlIgjxH_2423Dfe8In9_nRLB_PzKvlEV5Lpmzg4IowEFhawRGib3R1o74mgIb3SPeMLEAAA

トークンの値全体をコピーして、認証のためにログイン・ページのトークン・フィールドに貼り付けます。

ダッシュボードにリモートでアクセスする必要がある場合は、次の項で説明するとおり、SSHトンネリングを使用してローカル・ホストからプロキシ・ノードへのポート転送を行うことをお薦めします。

SSHトンネリング

最も簡単な方法は、SSHトンネリングを使用して、アクセス先のノードで実行中のプロキシ・サービスに構成されたポートに、ローカル・システムのポートを転送することです。この方法では、SSHトンネルによってHTTP接続が暗号化され、SSH構成によって認証が処理されるため、ある程度のセキュリティが保持されます。たとえば、ローカル・システムで次を実行します。 

$ ssh -L 8001:127.0.0.1:8001 192.0.2.10

192.0.2.10を、kubectl proxyを実行中のホストのIPアドレスに置き換えます。SSH接続が確立されたら、ローカル・ホストでブラウザを開き、http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/loginに移動して、リモートのKubernetesクラスタでホストされているダッシュボードにアクセスできます。認証には、ダッシュボードにローカル接続したときと同じトークン情報を使用します。

4.5 クラスタからのワーカー・ノードの削除

4.5.1 単一マスター・クラスタ

いつでも、クラスタからワーカー・ノードを削除できます。システムにインストールされて実行されているKubernetesコンポーネントをすべて完全に削除するには、kubeadm-setup.sh downコマンドを使用します。この操作は破壊的であるため、ワーカー・ノードでこれを実行しようとすると、スクリプトにより警告が表示され、アクションを続行するための確認が必要になります。このスクリプトにより、クラスタ構成からノードを削除する必要があることも示されます。 

# kubeadm-setup.sh down
[WARNING] This action will RESET this node !!!!
          Since this is a worker node, please also run the following on the master (if not already done)
          # kubectl delete node worker1.example.com
          Please select 1 (continue) or 2 (abort) :
1) continue
2) abort
#? 1
[preflight] Running pre-flight checks
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"
[reset] Removing kubernetes-managed containers
[reset] No etcd manifest found in "/etc/kubernetes/manifests/etcd.yaml", assuming external etcd.
[reset] Deleting contents of stateful directories: [/var/lib/kubelet /etc/cni/net.d /var/lib/dockershim]
[reset] Deleting contents of config directories: [/etc/kubernetes/manifests /etc/kubernetes/pki]
[reset] Deleting files: [/etc/kubernetes/admin.conf /etc/kubernetes/kubelet.conf \
        /etc/kubernetes/controller-manager.conf /etc/kubernetes/scheduler.conf

廃止したノードが検索されないように、クラスタを更新する必要があります。kubectl delete nodeコマンドを使用して、クラスタからノードを削除します。 

$ kubectl delete node worker1.example.com
node "test2.example.com" deleted

worker1.example.comを、クラスタから削除するワーカー・ノードの名前に置き換えます。

マスター・ノードでkubeadm-setup.sh downコマンドを実行する場合、クラスタをリカバリする唯一の方法は、バックアップ・ファイルからリストアすることです。これにより、クラスタ全体が効率的に破棄されます。スクリプトにより、これは破壊的なアクションであり、マスター・ノードで実行していることが警告されます。続行する前に、アクションを確認する必要があります。 

# kubeadm-setup.sh down
[WARNING] This action will RESET this node !!!!
          Since this is a master node, all of the clusters information will be lost !!!!
          Please select 1 (continue) or 2 (abort) :
1) continue
2) abort
#? 1
[preflight] Running pre-flight checks
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"
[reset] Removing kubernetes-managed containers
[reset] Deleting contents of stateful directories: [/var/lib/kubelet /etc/cni/net.d \
        /var/lib/dockershim /var/lib/etcd]
[reset] Deleting contents of config directories: [/etc/kubernetes/manifests /etc/kubernetes/pki]
[reset] Deleting files: [/etc/kubernetes/admin.conf /etc/kubernetes/kubelet.conf \
        /etc/kubernetes/controller-manager.conf /etc/kubernetes/scheduler.conf]
deleting flannel.1 ip link ...
deleting cni0 ip link ...
removing /var/lib/cni directory ...
removing /var/lib/etcd directory ...
removing /etc/kubernetes directory ...

4.5.2 高可用性クラスタ

高可用性クラスタからのワーカー・ノードの削除は同様のプロセスに従いますが、かわりにkubeadm-ha-setup downコマンドを使用します。この操作は破壊的であるため、ワーカー・ノードでこれを実行しようとすると、ユーティリティにより警告が表示され、アクションを続行するための確認が必要になります。このスクリプトにより、クラスタ構成からノードを削除する必要があることも示されます。 

# kubeadm-ha-setup down
[WARNING] This operation will clean up all kubernetes installations on this node
press [y] to continue ...
y
[INFO] Removing interface flannel.1

廃止したノードが検索されないように、クラスタを更新する必要があります。任意のマスター・ノードでkubectl delete nodeコマンドを使用して、クラスタからノードを削除します。 

$ kubectl delete node worker1.example.com
node "worker1.example.com" deleted

worker1.example.comを、クラスタから削除するノードの名前に置き換えます。

いずれかのマスター・ノードでkubeadm-ha-setupコマンドを実行する場合、クラスタをリカバリする唯一の方法は、バックアップ・ファイルからリストアすることです。

Copyright © 2012, 2020, Oracle and/or its affiliates. 法律上の注意点