各ポッドには、「一時停止コンテナ」と呼ばれる特別なコンテナが含まれています。一時停止コンテナに対応するイメージは、Kubernetesプラットフォームの一部です。一時停止コンテナに加えて、各ポッドには1つ以上の関連するユーザービジネスコンテナも含まれています。
Kubernetesがこのような特別な構造を持つPodの新しい概念を設計した理由
理由1： 一時停止コンテナは、ポッド全体のコンテナグループの状態を表すポッドのルートコンテナとして機能します。
理由2： ポッド内の複数のビジネスコンテナは、一時停止コンテナのIPと一時停止コンテナにアタッチされたボリュームを共有します。
Kubernetesは、各ポッドに「Pod IP」と呼ばれる一意のIPアドレスを割り当てます。ポッド内の複数のコンテナがポッドIPを共有します。Kubernetesは、クラスタ内の任意の2つのポッド間でTCP/IP経由の直接通信を有効にするために、基盤となるネットワークサポートが必要です。これは、仮想レイヤー2ネットワーク技術を使用して実現され、ポッド内のコンテナが他のホスト上のコンテナと直接通信できるようにします。
静的ポッドと通常のポッド
通常のポッド：
作成されると、通常のポッドはetcdに保存され、その後、Kubernetesマスターによって特定のノードにスケジュールされ、バインドされます。その後、対応するノード上のkubeletプロセスによって、ポッドは関連する一連のDockerコンテナにインスタンス化されます。ポッド内のコンテナが停止した場合、Kubernetesは自動的に問題を検出し、ポッドを再起動します（ポッド内のすべてのコンテナを再起動します）。ポッドが存在するノードがクラッシュした場合、ポッドは他のノードに再スケジュールされます。
静的ポッド： 静的ポッドはkubeletによって管理され、特定のノードのみに存在します。
これらはAPIサーバーを介して管理することはできず、ReplicationController（RC）、Deployment、またはDaemonSetと関連付けることはできません。また、kubeletはこれらに対してヘルスチェックを実行できません。静的ポッドは常にkubeletによって作成され、kubeletが存在するノードで常に実行されます。
静的ポッドを作成する方法は2つあります：設定ファイルを使用する方法とHTTPを使用する方法。
- 設定ファイルの方法： 最初に、kubeletの起動パラメーターで「config」パラメーターを設定して、kubeletが構成ファイルを監視するディレクトリを指定する必要があります。 kubeletは定期的にこのディレクトリをスキャンし、このディレクトリ内の.yamlまたは.jsonファイルに基づいてポッドを作成します。
静的ポッドのデプロイ：
- 静的ポッドを実行するノードを選択します。
[root@docker ~] $ ssh master
- 例えば、/etc/kubelet.dディレクトリを選択し、このディレクトリにウェブサーバーのポッド定義ファイル（例：/etc/kubelet.d/static-web.yaml）を配置します。
[root@my-node1 ~] $ mkdir /etc/kubelet.d/
[root@my-node1 ~] $ cat <<EOF >/etc/kubelet.d/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
EOF
- ノードのkubeletをこのディレクトリを使用するように構成します。 kubeletを起動するときに–pod-manifest-path=/etc/kubelet.d/パラメーターを追加します。 Fedoraシステムを使用している場合は、Kubelet構成ファイル/etc/kubernetes/kubeletに次の行を追加します。
...
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
...
- kubeletを再起動します。
[root@docker ~] systemctl restart kubelet
注： APIサーバーを介してポッドを直接管理できないため、マスターノードがこのポッドを削除しようとすると、その状態が保留中になり、削除されません。
- HTTPメソッ
ド： これについてはここでは説明しませんが、興味がある方は公式ドキュメントを参照してください。https://kubernetes.io/cn/docs/tasks/administer-cluster/static-pod/
エンドポイント：
ポッドのIPとコンテナポートの組み合わせは、「エンドポイント」という新しい概念を形成し、このポッド内のサービスプロセスの外部通信アドレスを表します。ポッドには複数のエンドポイントが存在する場合があります。たとえば、Tomcatをポッドとして定義する場合、ポートとサービスポートの両方を2つのエンドポイントとして公開できます。
イベント：
イベントは、最初の生成時間、最後の発生時間、繰り返し回数、イニシエータ、タイプ、およびイベントの原因を含むイベントの記録です。イベントは通常、特定のリソースに関連付けられ、トラブルシューティングの重要な参照となります。ノードの説明情報にはイベントが含まれ、ポッドにもイベントレコードがあります。
ポッドを作成できない状況に遭遇した場合、kubectl describe pod [ポッド名]を使用して問題を特定できます。
デモ：
$ kubectl get podを使用して現在のポッドの数を確認します。
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-deployment-5c6b9976cc-2qbkr 0/1 ContainerCreating 0 14s
nginx-deployment-5c6b9976cc-bqtvp 0/1 ContainerCreating 0 14s
nginx-deployment-5c6b9976cc-ttdrz 0/1 ContainerCreating 0 14s
$ kubectl describe pod [ポッド名]を使用して、ポッドの詳細情報を表示します。
[root@master ~]# kubectl describe pod nginx-deployment-5c6b9976cc-2qbkr
Events:
Type Reason Age From Message
Normal Scheduled 35s default-scheduler Successfully assigned default/nginx-deployment-5c6b9976cc-2qbkr to master
Warning FailedCreatePodSandBox 6s (x2 over 28s) kubelet, master Failed create pod sandbox: rpc error: code = Unknown desc = failed pulling image "gcr.io/google_containers/pause-amd64:3.0": Error response from daemon: Get https://gcr.io/v1/_ping: dial tcp 74.125.203.82:443: getsockopt: connection timed out
エラーなしで完全なポッドが作成された例は以下の通りです：
$ 完全なポッドを表示します
[root@master ~]# kubectl describe pod tomcat-6755d5587c-nfjst
Name: tomcat-6755d5587c-nfjst
Namespace: default
Node: master/192.168.60.24
Start Time: Wed, 18 Jul 2018 16:29:37 +0800
Labels: app=docker
pod-template-hash=2311811437
Annotations: <none>
Status: Running
IP: 172.17.0.2
Controlled By: ReplicaSet/tomcat-6755d5587c
Containers:
tomcat:
Container ID: docker://415acd35b6d4ed3effd26e2d9a958a56e83619243b0216690e0573a6c079bf1f
Image: daocloud.io/library/tomcat
Image ID: docker-pullable://daocloud.io/library/tomcat@sha256:1c39cc2e882b4169199888
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Wed, 18 Jul 2018 16:33:18 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-cbkfr (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-cbkfr:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-cbkfr
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: <none>
Events: <none>
ポッドの基本的な使用方法
ポッドの基本的な使用方法は、1つまたは複数のコンテナの組み合わせを作成できることです。
app=nginxという名前のポッドを作成します
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 5
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx ##container name
image: daocloud.io/library/nginx:1.13.0-alpine #container image address
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
別のシナリオでは、nginxコンテナとtomcatコンテナが密接に結合され、外部サービスを提供するために一緒にパッケージ化されるべきであり、これら2つのコンテナを1つのポッドにパッケージ化する必要があります。
nginxとtomcatのyamlファイルを次のように構成します。
[root@master test]# cat docker.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: docker-pod
spec:
replicas: 1
selector:
matchLabels:
app: test
template:
metadata:
labels:
app: test
spec:
containers:
- name: docker-nginx-docker
image: daocloud.io/library/nginx:1.13.0-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
- name: docker-tomcat-docker
image: daocloud.io/library/tomcat:8.5.21-jre8-alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
[root@master test]# kubectl create -f docker.yaml
パラメータの説明
ポッドの実行状況を確認します。
READY情報が2/2になっていることがわかります。これは、ポッド内の2つのコンテナが正常に実行されていることを示しています（ステータス：実行中）。
Dockerでコンテナを確認します。
ポッドの詳細情報を表示するには、2つのコンテナの定義と作成プロセスを見ることができます。イベント情報のイベント。
[root@master ~]# kubectl describe pod docker-pod-dc6b86f8d-7tjwp
Name: docker-pod-dc6b86f8d-7tjwp
Namespace: default
Node: master/192.168.60.24
Start Time: Fri, 31 Aug 2018 11:06:02 +0800
Labels: app=test
pod-template-hash=872642948
Annotations: <none>
Status: Running
IP: 172.16.219.106
Controlled By: ReplicaSet/docker-pod-dc6b86f8d
Containers:
docker-nginx-docker: ## コンテナ名
Container ID: docker://63d038a53c613e0dfdb62df957035f0ab54cc5428461c33f9cbcee0118815619
Image: daocloud.io/library/nginx:1.13.0-alpine ##コンテナイメージ
Image ID: docker-pullable://daocloud.io/library/nginx@sha256:5c36f962c506c379bd63884976489c9c5e700c1496a6e8ea13dc404b1d258f76
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Fri, 31 Aug 2018 11:06:17 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-c6m5g (ro)
docker-tomcat-docker:
Container ID: docker://42e0e6ee79860c5dac6a9103c549bd47422e8044f2c57046f6ad4dcca346f743
Image: daocloud.io/library/tomcat:8.5.21-jre8-alpine
Image ID: docker-pullable://daocloud.io/library/tomcat@sha256:96a11198cf980995e61d906ba65b1c86934ffc4c7e9381157d2aebd8981a4480
Port: 8080/TCP
Host Port: 0/TCP
State: Running
Started: Fri, 31 Aug 2018 11:07:20 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-c6m5g (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-c6m5g:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-c6m5g
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: <none>
Events: <none>
Pod構成管理のためのConfigMap
アプリケーションデプロイメントにおけるベストプラクティスの1つは、アプリケーションが必要とする構成情報をプログラム自体から分離することです。これにより、アプリケーションの再利用が向上し、異なる構成を介して柔軟な機能が可能になります。アプリケーションをコンテナイメージとしてパッケージ化した後、構成は環境変数またはマウントされたファイルを介してコンテナに注入できます。しかし、大規模なコンテナクラスターでは、異なる構成で複数のコンテナを構成することが複雑になる場合があります。Kubernetesはバージョン1.2から、ConfigMap（リソースオブジェクト）として知られる統合されたアプリケーション構成管理ソリューションを導入しました。
ConfigMapの概要
通常、ConfigMapは次の方法でコンテナによって使用されます：
- コンテナ内で環境変数を生成する。
- コンテナの起動コマンドの起動パラメーターを設定する（環境変数として設定する必要があります）。
- ファイルやディレクトリをコンテナ内にボリュームとしてマウントする。
ConfigMapは、Kubernetesシステム内に1つ以上のキーと値のペアを格納し、アプリケーションが使用します。これは変数の値（たとえば、apploglevel=info）または完全な構成ファイルの内容（server.xml=<?xml..>..など）を表すことができます。
ConfigMapはYAML構成ファイルを使用するか、直接kubectl create configmapを使用して作成できます。
ConfigMapの作成
ConfigMapを作成する方法は4つあります：
- コマンドラインでConfigMapのパラメーターを直接指定する、
--from-literalを使用します。 - ConfigMapを作成するためのファイルを指定する、
--from-file=<file>を使用します。 - ディレクトリを指定して、ディレクトリ内のすべての構成ファイルからConfigMapを作成します、
--from-file=<directory>を使用します。 - ConfigMapの標準的なYAMLファイルを準備し、それを作成するために
kubectl create -fを使用します。
1. YAMLファイルを使用してConfigMapを作成する
apiVersion: v1
kind: ConfigMap
metadata:
name: test-configmap
data:
key1: docker1
keydir: /var/data
説明：
name: ConfigMapの名前。data.key1:key1に対応する値。data.keydir:keydirに対応するマウントディレクトリ。
ConfigMapを作成し、検証した後、Pod内で使用できます。
2. --from-fileパラメータを使用してConfigMapを作成する
kubectl create configmap test-server.xml --from-file=server.xml
このコマンドは、ファイルserver.xmlの内容を使用して、test-server.xmlという名前のConfigMapを作成します。
3. --from-literalパラメータを使用してConfigMapを作成する
kubectl create configmap test-configmap --from-literal=loglevel=info --from-literal=appdatadir=/var/data
このコマンドは、指定されたリテラルloglevel=infoとappdatadir=/var/dataを持つtest-configmapという名前のConfigMapを作成します。
Pod内でのConfigMapの使用
(1) 環境変数を介したConfigMapの使用
まず、ConfigMapを作成します：
apiVersion: v1
kind: ConfigMap
metadata:
name: docker-configmap
data:
keyinfo: www.docker.com
dockerDir: /var/data
次に、ConfigMapを参照するPodを作成します：
apiVersion: v1
kind: Pod
metadata:
name: docker-pod
spec:
containers:
- name: configmap-pod
image: busybox
command: [ "/bin/sh", "-c", "env | grep config" ]
env:
- name: configmapPod
valueFrom:
configMapKeyRef:
name: docker-configmap
key: keyinfo
- name: configmapDir
valueFrom:
configMapKeyRef:
name: docker-configmap
key: dockerDir
restartPolicy: Never
このPodには、ConfigMapからの値で環境変数configmapPodとconfigmapDirが設定されます。
ConfigMapsの詳細を取得します。
(2) ボリュームマウントを介したConfigMapの使用
構成ファイル（たとえば、server.xml）を含むConfigMapを作成します。
apiVersion: v1
kind: ConfigMap
metadata:
name: tomcat-server-config
data:
server.xml: |
<?xml version='1.0' encoding='utf-8'?>
<Server port="8005" shutdown="SHUTDOWN">
<!-- Tomcatサーバーの構成 -->
<!-- ... -->
</Server>
次に、このConfigMapをPodで参
照します：
apiVersion: apps/v1
kind: Deployment
metadata:
name: docker-pod
spec:
replicas: 1
selector:
matchLabels:
app: tomcat
template:
metadata:
labels:
app: tomcat
spec:
containers:
- image: busybox
name: tomcatpod
volumeMounts:
- mountPath: /tmp/server.xml
name: serverxml
subPath: server.xml
ports:
- containerPort: 8080
command: ["tail", "-f", "/dev/null"]
volumes:
- name: serverxml
configMap:
name: tomcat-server-config
items:
- key: server.xml
path: server.xml
このPodには、ConfigMapからのserver.xmlファイルが、コンテナ内の/tmp/server.xmlにマウントされます。
/tempディレクトリにあるserver.xmlファイルを確認できます。
ConfigMapは、Kubernetesクラスターで実行されるアプリケーションの構成データを管理する柔軟性を提供し、簡単な更新と再利用が可能です。
ConfigMapの使用の要約
ConfigMapを使用する際の制限事項と考慮事項は次のとおりです：
- Podよりも前にConfigMapを作成する必要があります。
- ConfigMapは名前空間にバインドされています。同じ名前空間内のPodのみがそれを参照できます。
- ConfigMap内のクォータ管理はまだ実装されていません。
- Kubeletは、ConfigMapを参照するにはAPIサーバーによって管理されるPodのみをサポートできます。Kubeletによって自動的に作成されるこのノード上の静的Podは、
--manifest-urlまたは--configを介してConfigMapを参照できません。 - ボリュームマウントを使用してPod内のConfigMapをマウントする場合、コンテナ内にはディレクトリのみがマウントされ、ファイルはマウントされません。コンテナにマウントされると、ディレクトリにはConfigMapで定義された各アイテムが含まれます。ディレクトリに元々他のファイルが含まれている場合、それらはConfigMapにマウントされたもので上書きされます。アプリケーションが元のファイルを保持する必要がある場合は、追加の処理が必要です。ConfigMapは、コンテナ内の一時ディレクトリにマウントされ、起動スクリプト（たとえば、
cp linkなど）を介してアプリケーションによって使用される実際の構成ディレクトリに構成ファイルをコピーまたはリンクすることができます。 - ボリュームをマウントするだけではなく、コンテナを実行するためにコマンドを実行する必要があります。
- マウント時にSubPathを追加する必要があります。さもなければ、ディレクトリ全体が置換されます。