Kubernetes の YAML ファイル
Kubernetes の設定に関するその他多くの方法と同様に、YAML は Kubernetes 構成ファイルで使用される標準フォーマットです。YAML は広く使用されているため、多くの場合、すでに精通していると考えられます。そうでないと’しても、yaml は非常に簡単に学習できる言語であるため、たいした問題ではありません。ポッドの YAML 設定の各行は詳細であり、pod 学習プロセスの副産物として YAML 形式について理解しておく必要があります。
YAML 形式の pod 構成ファイルは次のとおりです。
YAML は、次の3つの基本データタイプを使用します。
スカラー (文字列/数値): atom データ項目、pod-1、ポート番号80のような文字列。
マッピング (ハッシュ/ディクショナリ): キーと値のペアを入れ子にすることもできます。apiVersion: v1 はマッピングです。key apiVersion は v1 の値を持っています。
シーケンス (アレイ/リスト): 順序付けられた値の収集。キーはありません。リストアイテムは、-標識で示されます。キーコンテナーの値は、2つのコンテナを含むリストです。
この例では、ネストした YAML データ構造も見られます。
マップのマッピング: spec はマップの鍵であり、pod’の仕様を定義します。この例では、pod で起動するコンテナの動作のみを定義しています。この値は、キーがコンテナに含まれるもう1つのマップです。
リストのマッピング。キーコンテナの値は、次の2つの項目のリストです。サーバーとクライアントのコンテナーです。各コンテナは、公開される名前、イメージ、ポートなどの属性を使用して、個々のコンテナを示すマッピングを示しています。
YAML に関して知っておく必要があるその他の特性は以下のとおりです。
大文字と小文字が区別されます。
同じレベルの要素は同じ左インデントを共有しますが、インデント幅は重要ではありません。
タブ文字をインデントとして使用することはできません。
空白ラインは重要ではありません
# を使用してラインにコメントをする
任意の文字の特殊な意味をエスケープするには、単一引用符を使用します。
YAML ファイルの詳細を確認する前に、次’のように pod の作成を完了させてみましょう。
$ kubectl create -f pod-2containers-do-one.yaml pod/pod-1 created $ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE pod-1 0/2 ContainerCreating 0 18s 10.47.255.237 cent333<none> $ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE pod-1 2/2 Running 0 18s 10.47.255.237 cent333 <none>
そこ。最初の Kubernetes オブジェクト–は pod-1 という名前の pod として作成されています。では、コンテナはどこにあるのでしょうか。この出力は、次のような手掛かりを提供します。2つのコンテナ (準備完了/2) を含む pod ポッド-1 (名前) は、Kubernetes worker ノード cent333 で、IP アドレス10.47.255.237 を割り当てて起動されています。ポッド内の両方のコンテナが稼働しています (準備完了 2/)。再起動なしで、27s の実行ステータスになっています。ここ’で yaml 構成が何を実行しているかについて、簡単な説明を示します。
ライン 1: このコメント行は、# 進んだテキストを使用して、YAML ファイルに任意のコメントを付けることができます。(本書全体では、この最初の行を使用して YAML ファイルのファイル名を指定しています。このファイル名は、YAML ファイルからオブジェクトを作成するときにコマンドの後で使用されます。
線2、3、4、8: 4 YAML のマッピングは、pod 定義の主なコンポーネントです。
ApiVersion: V2 など、さまざまなバージョンがあります。ここでは、特にバージョン1です。
同種Kubernetes オブジェクトには別のタイプがあることに注意してください。この場合、Kubernetes が pod オブジェクトを作成する必要があります。その後、他のオブジェクトの例では、レプリケーションコントローラまたはサービスの種類が表示されます。
データ作成されたオブジェクトを識別します。作成するオブジェクトの名前に加えて、別の重要なメタデータはラベルです。これについては、第3章で詳しく説明します。
スペシフィケーションこれにより、pod 動作に関する仕様が得られます。
ライン 9-15: Pod 仕様では、2つのコンテナについて説明しています。システムは画像をダウンロードし、各コンテナを名前で起動して、指定されたポートを公開します。
’ここでは’、ポッド内で実行されていることを示します。
$ kubectl describe pod pod-1 | grep -iC1 container IP: 10.47.255.237 Containers: server: Container ID: docker://9f8032f4fbe2f0d5f161f76b6da6d7560bd3c65e0af5f6e8d3186c6520cb3b7d Image: contrailk8sdayone/contrail-webserver -- client: Container ID: docker://d9d7ffa2083f7baf0becc888797c71ddba78cd951f6724a10c7fec84aefce988 Image: contrailk8sdayone/ubuntu -- Ready True ContainersReady True PodScheduled True -- Normal Pulled 3m2s kubelet, cent333 Successfully pulled image "contrailk8sdayone/contrail-webserver" Normal Created 3m2s kubelet, cent333 Created container Normal Started 3m2s kubelet, cent333 Started container Normal Pulling 3m2s kubelet, cent333 pulling image "contrailk8sdayone/ubuntu" Normal Pulled 3m1s kubelet, cent333 Successfully pulled image "contrailk8sdayone/ubuntu" Normal Created 3m1s kubelet, cent333 Created container Normal Started 3m1s kubelet, cent333 Started container
当然のことながら、pod-1 は、Kubernetes クラスターによって割り当てられた IP アドレスを使用して、YAML ファイル、サーバー、クライアントで宣言された2つのコンテナから成り、Figure 1に示すように、すべてのコンテナ間で共有しています。
コンテナの一時停止
Node cent333 にログインすると、次の’ような Docker コンテナが pod 内で実行されていることがわかります。
$ docker ps | grep -E "ID|pod-1" CONTAINER ID IMAGE COMMAND ... PORTS NAMES d9d7ffa2083f contrailk8sdayone/ubuntu "/sbin/init" ... k8s_client_pod-1_default_f8b42343-d87a-11e9-9a1e-0050569e6cfc_0 9f8032f4fbe2 contrailk8sdayone/contrail-webserver "python app-dayone.py" ... k8s_server_pod-1_default_f8b42343-d87a-11e9-9a1e-0050569e6cfc_0 969ec6d93683 k8s.gcr.io/pause:3.1 "/pause" ... k8s_POD_pod-1_default_f8b42343-d87a-11e9-9a1e-0050569e6cfc_0
K8s.gcr.io/pause の3番目のコンテナは、Kubernetes システムによってポッドごとに作成された特別なコンテナです。Pause コンテナは、pod のネットワークリソースを管理するために作成されます。この pod のすべてのコンテナで共有されます。
Figure 2は、いくつかのユーザーコンテナと一時停止コンテナを含むポッドを示しています。
内部ポッド通信
Kubernetes マスターでは、次’のようにマスターからのコンテナへのログインを許可します。
#login to pod-1's container client $ kubectl exec -it pod-1 -c client bash root@pod-1:/# #login to pod-1's container server $ kubectl exec -it pod-1 -c server bash root@pod-1:/app-dayone#
Docker でプレイしたことがあれば、これは非常にすばらしいものであることをすぐに実感してください。コンテナはいずれかのノードで起動されたので、Docker を使用する場合は、まず、適切なリモートノードにログインしてから、類似の Docker exec コマンドを使用して各コンテナーにログインする必要があります。Kubernetes は、このような詳細を隠します。これにより、1つのノード–からマスターのすべてを実行できます。
次に、コンテナで実行されているプロセスをチェックします。
サーバーコンテナ
root@pod-1:/app-dayone# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 55912 17356 ? Ss 12:18 0:00 python app-dayo root 7 0.5 0.0 138504 17752 ? Sl 12:18 0:05 /usr/bin/python root 10 0.0 0.0 18232 1888 pts/0 Ss 12:34 0:00 bash root 19 0.0 0.0 34412 1444 pts/0 R+ 12:35 0:00 ps aux root@pod-1:/app-dayone# ss -ant State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:80 *:* LISTEN 0 128 *:22 *:* LISTEN 0 128 :::22 :::* root@pod-1:/app-dayone# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 116: eth0@if117: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:f8:e6:63:7e:d8 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.47.255.237/12 scope global eth0 valid_lft forever preferred_lft forever
クライアントコンテナ
$ kubectl exec -it pod-1 -c client bash root@pod-1:/# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 32716 2088 ? Ss 12:18 0:00 /sbin/init root 41 0.0 0.0 23648 888 ? Ss 12:18 0:00 cron root 47 0.0 0.0 61364 3064 ? Ss 12:18 0:00 /usr/sbin/sshd syslog 111 0.0 0.0 116568 1172 ? Ssl 12:18 0:00 rsyslogd root 217 0.2 0.0 18168 1916 pts/0 Ss 12:45 0:00 bash root 231 0.0 0.0 15560 1144 pts/0 R+ 12:45 0:00 ps aux root@pod-1:/# ss -ant State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:80 *:* LISTEN 0 128 *:22 *:* LISTEN 0 128 :::22 :::* root@pod-1:/# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 116: eth0@if117: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:f8:e6:63:7e:d8 brd ff:ff:ff:ff:ff:ff inet 10.47.255.237/12 scope global eth0 valid_lft forever preferred_lft forever
この ps コマンド出力は、各コンテナーが独自のプロセスを実行していることを示しています。しかし、ss と ip のコマンド出力は、両方のコンテナが同一の正確なネットワーク環境を共有しているため、どちらもポートを相互に公開していることを示しています。そのため、localhost を使用するだけで、pod 内のコンテナ間の通信が発生する可能性があります。ここ’では、curl コマンドを使用して TCP 接続を開始することで、これをテストしてみましょう。
クライアントコンテナから、サーバーコンテナから web ページを取得したいとします。次のように localhost の IP アドレスを使用して curl を開始するだけです。
root@pod-1:/# curl localhost <html> <style> h1 {color:green} h2 {color:red} </style> <div align="center"> <head> <title>Contrail Pod</title> </head> <body> <h1>Hello</h1><br><h2>This page is served by a <b>Contrail</b> pod</h2><br><h3>IP address = 10.47.255.237<br>Hostname = pod-1</h3> <img src="/static/giphy.gif"> </body> </div> </html>
接続が確立し、web ページが正常にダウンロードされたことを確認できます。
では’、TCP 接続の状態を監視してみましょう。接続が正常に確立されました。
root@pod-1:/# ss -ant State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:80 *:* LISTEN 0 128 *:22 *:* TIME-WAIT 0 0 127.0.0.1:80 127.0.0.1:34176 #<--- LISTEN 0 128 :::22 :::*
また、サーバーコンテナからも同じように正確に接続できます。
$ kubectl exec -it pod-1 -c server bash root@pod-1:/app-dayone# ss -ant State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:80 *:* LISTEN 0 128 *:22 *:* TIME-WAIT 0 0 127.0.0.1:80 127.0.0.1:34176 #<--- LISTEN 0 128 :::22 :::*
Kubectl ツール
ここまでは’、kubectl コマンドによって作成されたオブジェクトを見てきました。このコマンドは、Docker world の docker コマンドと同様に、Kubernetes world のインターフェイスが Kubernetes API 経由でクラスター、より正確に Kubernetes master と通信します。’Kubernetes に対処するために必要なあらゆる種類のタスクを実行するためのオプションを提供する汎用ツールです。
Kubectl のオートコンプリート機能を有効にした場合、現在の環境でサポートされるすべてのオプションを一覧表示するには、マスターと入力 kubectl にログインし、次に2つの tab キーを使用します。
root@test1:~# kubectl<TAB><TAB> alpha attach completion create exec logs proxy set wait annotate auth config delete explain options replace taint api-resources autoscale convert describe patch rollout top api-versions certificate drain get plugin run uncordon apply cluster-info cp edit label port-forward scale version expose cordon
Kubectl コマンドのオートコンプリートを設定するには、[完了] オプションの指示に従ってください。
kubectl の完了-h
このガイドの残り’の部分では、これらのオプションのいくつかについて説明しています。