Kubernetes のコンテナタイプを調べる

序文

Kubernetes では、コンテナは Pod でデプロイおよび管理されます。 Pod は、Kubernetes オブジェクト モデル内で作成、デプロイ、管理できる最小かつ最もシンプルな単位です。ここでは、単一のポッド内で異なるコンテナ タイプを使用して、特定の機能を実装できます。 Kubernetes で使用される一般的なコンテナ タイプを次に示します。

• コンテナの初期化: コンテナを初期化する
• サイドカーコンテナ:
• エフェメラルコンテナ: 一時コンテナ
• マルチコンテナ:

初期化コンテナ

Pod では、アプリケーションを実行するために複数のコンテナを実行できますが、アプリケーション コンテナが起動する前に実行される 1 つ以上の init コンテナも実行できます。 Init コンテナは、メイン アプリケーション コンテナが起動する前に初期化タスクを実行するように設計されています。これらは、構成ファイルの設定、データベースの初期化、外部サービスの準備完了の待機などのタスクに使用できます。 Init コンテナは、次の点を除いて、通常のコンテナとまったく同じです。

• 初期化コンテナは常に完了まで実行されます。
• 次の init コンテナを起動するには、各 init コンテナが正常に完了する必要があります。

場合

apiVersion: v1 kind: Pod metadata: name: nginx-init labels: app: nginx spec: initContainers: #Initializing container - name: init-container image: alpine command: ['sh', '-c', 'echo "<h1>This is from INIT container</h1>" >> /usr/share/nginx/html/index.html'] volumeMounts: - name: data mountPath: /usr/share/nginx/html containers: # application container ie, main container - name: app image: nginx volumeMounts: - name: data mountPath: /usr/share/nginx/html volumes: - name: data emptyDir: {}

ここでの init-container は、データ ボリューム データを使用して、nginx ホームページの index.html を上書きします。

サービスオーケストレーションファイル

apiVersion: v1 kind: Service metadata: name: nginx-svc labels: app: nginx spec: type: NodePort selector: app: nginx ports: - port: 80 targetPort: 80

ポッドとサービスを作成する

kubectl apply -f nginx-init.yaml kubectl apply -f nginx-service.yaml

ここで、ブラウザから nginx エンドポイントにアクセスしようとすると、次の出力が表示されます。

画像

サイドカーコンテナ

サイドカー コンテナは、メイン アプリケーション コンテナと同じ Pod で実行されるセカンダリ コンテナです。これらのコンテナーは、メイン アプリケーション コードを直接変更せずに、ログ記録、監視、セキュリティ、データ同期などの追加のサービスや機能を提供することで、メイン アプリケーション コンテナーの機能を強化または拡張するために使用されます。

サイドカー コンテナを使用する例:

nginx-sidecar.yaml を作成します:

 apiVersion: v1 kind: Pod metadata: name: nginx-pod labels: app: nginx spec: containers: #App container - name: nginx-container image: nginx:latest ports: - containerPort: 80 volumeMounts: - name: logs mountPath: /var/log/nginx #This is side container - name: sidecar-container image: busybox command: ["/bin/sh"] args: ["-c", "tail -f /var/log/nginx/access.log"] volumeMounts: - name: logs mountPath: /var/log/nginx volumes: - name: logs emptyDir: {}

上記の Pod には 2 つのコンテナが含まれています。1 つはアプリケーション コンテナ (nginx) で、もう 1 つはメイン アプリケーションの nginx アクセス ログを収集するために使用するサイドカー コンテナです。

nginx-svc.yaml を作成します:

 apiVersion: v1 kind: Service metadata: name: nginx-svc labels: app: nginx spec: type: NodePort selector: app: nginx ports: - port: 80 targetPort: 80

ポッドとサービスを作成する

kubectl apply -f nginx-sidecar.yaml kubectl apply -f nginx-svc.yaml

ブラウザから nginx エンドポイントにアクセスしようとすると、nginx のウェルカム ページが表示されます。次に、以下のコマンドを使用してサイドカー ログにアクセスしようとすると、最新のアクセスのアクセス ログが取得されます。

 kubectl logs nginx-pod -c sidecar-container k logs nginx-pod -c sidecar-container 10.244.0.1 - - [17/Jan/2024:18:25:02 +0000] "GET / HTTP/1.1" 200 615 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" "-" 10.244.0.1 - - [17/Jan/2024:18:25:02 +0000] "GET /favicon.ico HTTP/1.1" 404 555 "http://127.0.0.1:53471/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" "-" 10.244.0.1 - - [17/Jan/2024:18:25:24 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" "-" 10.244.0.1 - - [17/Jan/2024:18:25:25 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" "-"

一時コンテナ

エフェメラル コンテナーは、リソースや実行の保証がなく、自動的に再起動されることがないため、アプリケーションの構築には適していないという点で他のコンテナーとは異なります。エフェメラル コンテナーは通常のコンテナーと同じ ContainerSpec を使用して記述されますが、多くのフィールドはエフェメラル コンテナーに対して互換性がなく、禁止されています。

エフェメラル コンテナーにはポートがない場合があるため、ポート、ライブネス プローブ、準備プローブなどのフィールドの使用は禁止されています。 Pod リソースの割り当ては不変であるため、リソースの設定は禁止されています。

エフェメラル コンテナは、コンテナがクラッシュした場合やコンテナ イメージにデバッグ ツールが含まれていない場合など、kubectl exec を使用しても問題を解決できない場合に、対話型のトラブルシューティングを行うのに役立ちます。

Pod をデバッグするには 2 つの方法があります。

a.デバッグ用の一時コンテナの使用

Pod は実行中だが実行できない場合は、このアプローチを使用できます。 kubectl debug コマンドを使用して、実行中の Pod に一時コンテナを追加できます。このアプローチでは、同じ Pod 内に新しいコンテナが作成されます。

 kubectl debug -it <RUNNING-POD> --image=<DEBUG-IMAGE>:<DEBUG-IMAGE-TAG> --target=<RUNNING-CONTAINER>

<podname> を既存の Pod 名に置き換え、<containername> をデバッグする既存のコンテナに置き換えます。このコマンドは、新しい busybox コンテナを追加し、それにアタッチします。

b.デバッグにはポッドのコピーを使用する

Pod がクラッシュしてアクセスできない場合は、この方法を使用できます。このアプローチでは、元の Pod のコンテナとともに新しいデバッグ コンテナを含む新しい Pod が作成されます。

 kubectl debug <ORIGINAL-POD> -it --image=<DEBUG-IMAGE>:<DEBUG-IMAGE-TAG> --share-processes --copy-to=<NEW-DEBUG-POD>

元の Pod 名を ORIGINAL-POD に置き換え、新しいデバッグ Pod 名を NEW-DEBUG-POD に置き換えてください。新しいデバッグ Pod は元の Pod のコピーです。

場合

ephemeral-pod.yaml を作成します。

 apiVersion: v1 kind: Pod metadata: name: ephemeral-pod spec: containers: - image: registry.k8s.io/pause:3.1 name: ephemeral-container restartPolicy: Never

この YAML ファイルは、デバッグ ツールなしで一時停止されたコンテナ イメージを作成します。

 kubectl apply -f ephermeral-pod.yaml

上記のコマンドは、デフォルトの名前空間に一時的な Pod を作成します。

 k get po NAME READY STATUS RESTARTS AGE ephemeral-pod 1/1 Running 0 3m41s

次のコマンドを使用して実行してみます。

 kubectl exec -it ephemeral-pod -- sh

ただし、このコンテナイメージにはシェルがないため、次のエラーが発生します。

 kubectl exec -it ephemeral-pod -- sh OCI runtime exec failed: exec failed: unable to start container process: exec: "sh": executable file not found in $PATH: unknown command terminated with exit code 126

ここで、一時コンテナであるデバッグ コンテナを使用して Pod に入ってみましょう。

次のコマンドを使用して、一時コンテナを作成し、それを上記のポッド ephemeral-pod に接続します。

 kubectl debug -it ephemeral-pod --image=busybox --target=ephemeral-container

このコマンドは、新しい busybox コンテナを追加し、それを一時ポッドに接続します。 --target パラメータは、実行するコンテナを指定します。さらに、コマンドは一時コンテナのコンソールに自動的に接続します。

出力：

 kubectl debug -it ephemeral-pod --image=busybox --target=ephemeral-container Targeting container "ephemeral-container". If you don't see processes from this container it may be because the container runtime doesn't support this feature. Defaulting debug container name to debugger-q6svq. If you don't see a command prompt, try pressing enter. / # / #

これで、実際のコンテナ（一時的なコンテナ）にアクセスしてデバッグできるようになります。

マルチコンテナ

Kubernetes を使用すると、並列に実行される複数のコンテナを持つ Pod を定義できます。コンテナは同じネットワーク名前空間を共有し、localhost 経由で相互に通信できます。これらのマルチコンテナ ポッドは、リソースとデータを共有しながら、密に結合されたプロセスを一緒に実行する必要があるシナリオを対象としています。

場合

nginx-multi-container-pod.yaml を作成します。

 apiVersion: v1 kind: Pod metadata: name: nginx-pod labels: app: nginx spec: containers: #App container - name: nginx-container image: nginx:latest ports: - containerPort: 80 volumeMounts: - name: data mountPath: /usr/share/nginx/html #This is extra container - name: extra-container image: debian command: ["/bin/sh", "-c"] args: - while true; do date > /usr/share/nginx/html/index.html; sleep 1; done volumeMounts: - name: data mountPath: /usr/share/nginx/html volumes: - name: data emptyDir: {}

上記のマニフェスト ファイルには 2 つのコンテナーがあります。1 つはメイン アプリケーション (nginx) で、もう 1 つは nginx Web アプリケーションのホームページを継続的に更新するのに役立つ追加のコンテナーです。

nginx-svc.yaml を作成します:

 apiVersion: v1 kind: Service metadata: name: nginx-svc labels: app: nginx spec: type: NodePort selector: app: nginx ports: - port: 80 targetPort: 80

ポッドとサービスの作成

kubectl apply -f nginx-multi-container-pod.yaml kubectl apply -f nginx-svc.yaml

ここで、ブラウザ経由で nginx エンドポイントにアクセスしようとすると、上記の追加コンテナによって更新された日付が表示されます。