第4章 Kubernetes のトラブルシューティング

Kubernetes サービスとして実行できるアプリケーションの種類には制限があるため、すべてのアプリケーションを一律に kubernetes に対応させることはできません。Kubernetes におけるサービスは、IP アドレスがサービスのクライアントの iptables に挿入される負荷分散プロキシーです。したがって、Kubernetes にデプロイする予定のアプリケーションについては、以下に該当するかを確認する必要があります。

上記のいずれかに関連する制限が適用されないか、またはユーザーがそれらの確認項目を無効にできる場合は、このまま継続することができます。

実行しているソフトウェアの種類によって、Kubernetes サービスのクライアントに提供される事前に定義された一部の環境変数を利用できる場合があります。

たとえば、db という名前のサービスの場合、そのサービスを使用する Kubernetes で Pod を起動する場合、Kubernetes は以下の環境変数を Pod のコンテナーに挿入します。

DB_SERVICE_PORT_3306_TCP_PORT=3306
DB_SERVICE_SERVICE_HOST=10.254.100.1
DB_SERVICE_PORT_3306_TCP_PROTO=tcp
DB_SERVICE_PORT_3306_TCP_ADDR=10.254.100.1
DB_SERVICE_PORT_3306_TCP=tcp://10.254.100.1:3306
DB_SERVICE_PORT=tcp://10.254.100.1:3306
DB_SERVICE_SERVICE_PORT=3306

注意: サービス名 (db) は、変数では DB のように大文字で表示されることに注意してください。名前に使用されるダッシュ (-) は、アンダースコア (_) に変換されます。

これらの変数を含むシェル変数を確認するには、docker exec を実行してアクティブなコンテナーにシェルを開き、env を実行してシェル変数を確認します。

# docker exec -it <container_ID> /bin/bash
[root@e7ea67..]# env
...
WEBSERVER_SERVICE_SERVICE_PORT=80
KUBERNETES_RO_SERVICE_PORT=80
KUBERNETES_SERVICE_PORT=443
KUBERNETES_RO_PORT_80_TCP_PORT=80
KUBERNETES_SERVICE_HOST=10.254.255.128
DB_SERVICE_PORT_3306_TCP_PORT=3306
DB_SERVICE_SERVICE_HOST=10.254.100.1
WEBSERVER_SERVICE_PORT_80_TCP_ADDR=10.254.100.50
...

クライアントアプリケーションを起動する際に、これらの変数を利用する必要がある場合があります。たとえば、「Kubernetes クラスターを作成して Docker フォーマットのコンテナーイメージを実行する」で説明されているように Web サーバーや Database アプリケーションを作成する場合、Web サーバーがデプロイする action スクリプトは DB_SERVICE_SERVICE_HOST の値を取得するため、データベースサービスにアクセスするために使用できる IP アドレスを認識できます。

コンテナー間の通信の問題をデバッグする際にこれらのシェル変数を表示すると、サービスおよびポートのアドレスをコンテナーごとに表示するのに役立ちます。

Kubernetes Master から、実行中の Kubernetes 設定を検査します。上述したように、このセクションのトラブルシューティングの例は、「Kubernetes クラスターを作成して Docker フォーマットのコンテナーイメージを実行する」に記載されている設定で実行されます。

まず、すべての設定を有効にした場合どのように表示されるかについて説明します。次に、セットアップに発生する各種の問題とその修正方法を示します。

アプリケーションの送信とサービスの作成、 Pod の割り当てのプロセスを手動でデバッグするには、kubectl を使用するのが一番簡単です。どの Pod、サービス、およびレプリケーションコントローラーがアクティブであるかを確認するには、マスターで以下のコマンドを実行します。

# kubectl get pods
POD             IP          CONTAINER(S)     IMAGE(S)  HOST                LABELS                                         STATUS
4e04dd3b-c...   10.20.29.3  apache-frontend  webwithdb node2.example.com/  name=webserver,selectorname=webserver,uses=db  Running
5544eab2-c...   10.20.48.15 apache-frontend  webwithdb node1.example.com/  name=webserver,selectorname=webserver,uses=db  Running
1c971a09-c...   10.20.29.2  db               dbforweb  node2.example.com   name=db,selectorname=db                        Running
1c97a755-c...   10.20.48.14 db               dbforweb  node1.example.com/  name=db,selectorname=db                        Running
# kubectl get services
NAME               LABELS                                   SELECTOR        IP                  PORT
webserver-service  name=webserver                           name=webserver  10.254.100.50       80
db-service         name=db                                  name=db         10.254.100.1        3306
kubernetes         component=apiserver,provider=kubernetes            10.254.92.19        443
kubernetes-ro      component=apiserver,provider=kubernetes            10.254.206.141      80
# kubectl get replicationControllers
CONTROLLER             CONTAINER(S)        IMAGE(S)            SELECTOR                 REPLICAS
webserver-controller   apache-frontend     webwithdb           selectorname=webserver   2
db-controller          db                  dbforweb            selectorname=db          2

以下に、この出力が何を示しているかを説明します。

この状態になるまでのプロセスで問題が発生した場合は、以下のセクションを参照してトラブルシューティングを行うことができます。

Kubernetes クラスターは、マスターと 1 つ以上のノード (minion) で構成されており、systemd サービスの特定セットを初期化する必要があります。マスターおよび各ノードで以下のサービスが実行していることを確認する必要があります。

以下は、マスターおよび各ノード上でこれらのサービスを確認する方法です。

マスター: kubernetes マスターサーバーでは、適切なサービスがアクティブであり、有効にされているかどうかが示されます (flanneld はシステムに設定されていない場合もあります)。

# for SERVICES in etcd flanneld kube-apiserver kube-controller-manager kube-scheduler;
    do echo --- $SERVICES --- ; systemctl is-active $SERVICES ;
    systemctl is-enabled $SERVICES ; echo "";  done
--- etcd ---
active
enabled
--- flanneld ---
active
enabled
--- kube-apiserver ---
active
enabled
--- kube-controller-manager ---
active
enabled
--- kube-scheduler ---
active
enabled

Minions (ノード): 各ノードで、適切なサービスがアクティブであり、有効にされていることを確認します。

# for SERVICES in flanneld docker kube-proxy.service kubelet.service; \
do echo --- $SERVICES --- ; systemctl is-active $SERVICES ; \
systemctl is-enabled $SERVICES ; echo "";  done
--- flanneld ---
active
enabled
--- docker ---
active
enabled
--- kube-proxy.service ---
active
enabled
--- kubelet.service ---
active
enabled

マスターまたはノードの systemd サービスのいずれかが無効にされているか、またはこれに障害がある場合は、以下を実行します。

RHEL Atomic には iptables または firewalld サービスはインストールされていません。そのため、デフォルトでは Kubernetes サービスへのアクセスをブロックするファイアウォールのフィルタールールはありません。ただし、RHEL ホストでファイアウォールが実行している場合や、Kubernetes マスターまたはノードに iptables ファイアウォールルールを追加して入力ポートにフィルターを設定している場合は、これらのシステムに公開する必要があるポートがブロックされていないことを確認する必要があります。

以下は netstat コマンドの出力であり、Kubernetes および関連サービスが Kubernetes ノードで listen しているポートを示しています。

# netstat -tupln
tcp6       0      0 :::10249          :::*          LISTEN      125528/kube-proxy
tcp6       0      0 :::10250          :::*          LISTEN      125536/kubelet

注意: kube-proxy サービスはランダムなポートで listen します。デフォルトで使用されているファイアウォールサービスにフィルタリングが使用されているため、これは RHEL Atomic システムでは問題ありません。ただし、ファイアウォールを RHEL Atomic に追加するか、またはデフォルトの RHEL システムを使用する場合、サービス定義で kube-proxy が特定のポートで listen し、ファイアウォールでそれらのポートを開くように設定することができます。

以下は、Kubernetes マスターにおける netstat 出力です。

tcp        0      0 192.168.122.249:7080  0.0.0.0:* LISTEN   636/kube-apiserver
tcp6       0      0 :::8080               :::*      LISTEN   636/kube-apiserver
tcp        0      0 127.0.0.1:10252       0.0.0.0:* LISTEN   7541/kube-controller
tcp        0      0 127.0.0.1:10251       0.0.0.0:* LISTEN   7590/kube-scheduler
tcp6       0      0 :::4001               :::*      LISTEN   941/etcd
tcp6       0      0 :::7001               :::*      LISTEN   941/etcd

kubectl create コマンドを使用して、yaml または json ファイルから情報をロードし、Kubernetes 環境 (Pod、サービス、およびレプリケーションコントローラー) をセットアップします。それらのファイルが正しくフォーマットされていなかったり、必要な情報が不足していると失敗します。

以下のセクションでは、yaml または json ファイルが破損している場合に生じる問題を解決するためのヒントを紹介します。

id: "db-service"
kind: "Service"
apiVersion: "v1beta1"
port: 3306
portalIP: "10.254.100.1"
selector:
  name: "db"
labels:
  name: "db"

# kubectl create -f db-service
# kubectl get services
NAME          LABELS                                  SELECTOR  IP             PORT
db-service    name=db                                 name=db   10.254.100.1   3306
kubernetes-ro component=apiserver,provider=kubernetes     10.254.186.33  80
kubernetes    component=apiserver,provider=kubernetes     10.254.198.9   443

id: "webserver-controller"
kind: "ReplicationController"
apiVersion: "v1beta1"
desiredState:
  replicas: 2
  replicaSelector:
    selectorname: "webserver"
  podTemplate:
    desiredState:
      manifest:
        version: "v1beta1"
        id: "webserver-controller"
        containers:
          - name: "apache-frontend"
            image: "webwithdb"
            ports:
              - containerPort: 80
    labels:
      name: "webserver"
      selectorname: "webserver"
      uses: "db"
labels:
  name: "webserver-controller"

# kubectl create -f webserver-service.yaml
# kubectl get pods
POD         IP          CONTAINER(S)     IMAGE(S)    HOST
       LABELS                                             STATUS
f28980d...  10.20.48.4  apache-frontend  webwithdb   node1.example.com/
       name=webserver,selectorname=webserver,uses=db      Running
f28a0a8...  10.20.29.9  apache-frontend  webwithdb   node2.example.com/
       name=webserver,selectorname=webserver,uses=db      Running
# kubectl get replicationControllers
CONTROLLER           CONTAINER(S)    IMAGE(S)   SELECTOR               REPLICAS

webserver-controller apache-frontend webwithdb  selectorname=webserver 2

etcd サービスは、Kubernetes がクラスター間で情報を統合するために使用するデータベースを提供します。データベースを直接表示して問題を修正する方法があります (または、修正ができない場合はデーターベースを削除します)。

etcd データベースからのデータの表示: kubectl get コマンドを使用して etcd データベースから必要な情報のほとんどを照会できます。ただし、このデータベースが設定が予想したものと異なる場合は、etcdctl コマンドを使用して etcd データベースを直接照会できます。

etcdctl コマンドを ls オプションと共に使用すると、データベースのディレクトリー構造を一覧表示できます。値を取得するには、get オプションを使用します。たとえば、データベースの root を表示するには、以下を入力します。

# etcdctl ls /
/coreos.com
/registry

etcd データベースの Kubernetes イベントを一覧表示するには、以下を入力します。

# etcdctl ls /registry/events/default/

/registry/events/default/679ec44e-e882-11e4-926b-52540...
/registry/events/default/e1f4b268-e87d-11e4-926b-52540...
/registry/events/default/node2.example.com.13d8e2c0b644c20b
/registry/events/default/679ec44e-e882-11e4-926b-52540...
/registry/events/default/5271ec4f-edc1-11e4-8ee6-52540...
/registry/events/default/node1.example.com.13d8e29653ad9bbc

データが特定のイベントに関連付けられていることを確認するには、get オプションを使用します (node1 引数を /registry/events/default/ ディレクトリーのエントリーに置き換えます)。

# etcdctl get \
  /registry/events/default/node1.example.com.13d8e29653ad9bbc | \
  python -mjson.tool
{
    "apiVersion": "v1beta1",
    "creationTimestamp": "2015-04-27T09:40:16-04:00",
    "host": "node1.example.com",
    "id": "node1.example.com.13d8e29653ad9bbc",
    "involvedObject": {
        "kind": "Minion",
        "name": "node1.example.com",
        "namespace": "default",
        "uid": "node1.example.com"
    },
    "kind": "Event",
    "message": "Starting kubelet.",
    "namespace": "default",
    "reason": "starting",
    "source": "kubelet",
    "timestamp": "2015-04-27T09:40:16-04:00",
    "uid": "f020d047-ece2-11e4-8ee6-5254001aa4ee"
}

上記の出力は python の json.tool フォーマットのモジュールにパイプされ、読みやすくなります。node1.example.com は Minion として定義され、それに関連付けられているイベントが kublet サービスを起動していることを確認できます。

以下は、その他の etcdctl を使用した ls の実行例です。これらは、レジストリーにあるトップレベルのエントリー、minions の名前、サービスの名前、および使用されているサブネットを示しています。

# etcdctl ls /registry/
/registry/events
/registry/minions
/registry/nodes
/registry/pods
/registry/services
/registry/controllers
# etcdctl ls /registry/minions
/registry/minions/node1.example.com
/registry/minions/node2.example.com
# etcdctl ls /registry/services/endpoints/default/
/registry/services/endpoints/default/db-service
/registry/services/endpoints/default/kubernetes
/registry/services/endpoints/default/kubernetes-ro
/registry/services/endpoints/default/webserver-service
# etcdctl ls /coreos.com/network/subnets/
/coreos.com/network/subnets/10.20.1.0-24
/coreos.com/network/subnets/10.20.24.0-24
/coreos.com/network/subnets/10.20.56.0-24

以下は、etcdctl を使用した get の実行例です。最初の例は、db サービスの詳細を示しています。2 つ目の例は、node1 のホスト IP アドレスおよび他の情報について示しています。最後の例は、flannel によって割り当てられるサブネットワークの情報を示しています。

# etcdctl get \
    /registry/services/endpoints/default/db-service/  \
    |  python -mjson.tool
{
    "apiVersion": "v1beta1",
    "creationTimestamp": "2015-04-21T18:29:43-04:00",
    "endpoints": [
        "10.20.1.3:3306",
        "10.20.24.3:3306"
    ],
    "id": "db-service",
    "kind": "Endpoints",
    "namespace": "default",
    "resourceVersion": 312,
    "selfLink": "/api/v1beta1/endpoints/db-service?namespace=default",
    "uid": "e87f9435-e875-11e4-926b-5254001aa4ee"
}
# etcdctl get /registry/minions/node1.example.com | python -mjson.tool

{
    "apiVersion": "v1beta1",
    "creationTimestamp": "2015-04-21T16:59:22-04:00",
    "hostIP": "192.168.122.116",
    "id": "node1.example.com",
    "kind": "Minion",
    "resources": {
        "capacity": {
            "cpu": "1",
            "memory": 3221225472
        }
    },
    "status": {},
    "uid": "4926bc0c-e869-11e4-926b-5254001aa4ee"
}
# etcdctl get /coreos.com/network/subnets/10.20.24.0-24 | python -mjson.tool

{
    "BackendData": {
        "VtepMAC": "86:b1:2e:96:5f:35"
    },
    "BackendType": "vxlan",
    "PublicIP": "192.168.122.116"
}

注意: etcdctl が選択できない場合は、curl コマンドを代わりに使用できます。たとえば、curl でデータベースの root を表示するには、etcdctl ls / コマンドの代わりに curl -L http://master:4001/v2/keys/ | python -mjson.tool を使用します。この curl コマンドの形式を使用して、ディレクトリーとキー値の両方を表示します。ノードをマスターの etcd サービスに接続できないと思われる場合は、以下の curl コマンドを使用して、ノードからその接続をテストできます。

# curl -s -L http://master.example.com:4001/version

etcd データベースの修正: 情報が同期されない場合、etcd データベースで問題を修正することができます。キーの内容を変更するためのコマンドには、etcdctl update および etcdctl set コマンドがあります。ただし、注意して使用しないと、これらの値を変更した時に、問題を修正せずに別の問題を発生させることになります。

ただし、etcd データベースが完全に利用できない場合は、一度削除してから再度起動できます。etcd デーモンを -f オプションと共に実行することにより、これを実行できます。

警告: etcd データベースを削除する前に、kubectl delete コマンドを使用して、問題のあるサービス、Pod、レプリケーションコントローラーまたは minions を削除します。データベースを削除する必要が依然としてあると思われる場合は、すべてを最初から作成し直す必要があることに注意してください。

etcd データベースを削除するには、以下を入力します。

# etcd -f

Kubernetes のコンポーネントを停止し、削除するには注意が必要です。Kubernetes は物事を特定の状態に維持するように設計されているため、コンテナーや Pod を削除するだけで、別のコンポーネントが起動することがよくあります。そのため、Kubernetes 環境で一部またはすべてのコンポーネントを削除する必要がある場合は、「Kubernetes クラスターの作成」の「Kubernetes の削除」サクションにある指示に従うことをお勧めします。

コンポーネントを削除する順番を間違えると、以下のような問題が発生します。

Pod は一定期間「waiting (待機状態)」状態になることがあります。以下が考えられる原因です。

コンテナーセッションから出力全体を確認できるようにする必要があります。たとえば、コンテナーにシェルを開いた場合、docker logs を実行する際にシェルから実行したすべてのコマンドを確認できます。