本記事の内容
前回に引き続いてUdemyのKubernetes Certified Application Developer (CKAD) with Testsというコースを受講していた中で気になったところをメモしていきます。
今回は以下のセクションに基づいています
#4 Multi-Container Pods
#5 Observability
#6 POD Design
勉強記
initContainer
- アプリケーションコンテナの前に実行される特殊なコンテナ
- spec.initContainersフィールドに詳細を記述(containersと同じ階層になる)
- 複数コンテナを指定できる。各コンテナは同時実行ではなく順番に実行される。
Pod に複数の init コンテナを指定した場合、kubelet は各 init コンテナを順番に実行します。各 init コンテナが成功しないと、次の init コンテナは実行されません。すべての init コンテナの実行が完了すると、kubelet は Pod のアプリケーション コンテナを初期化し、通常どおり実行します
- sidecarコンテナと違って、継続的に実行されるわけではなく、タスクを完了すると消滅する。
readinessProbe/livenessProbe
readinessProbe
- コンテナがトラフィックを受け入れる準備ができているかどうかを確認する
- 準備が出来ていないと判断された場合、当該Podへはトラフィックが流れない
livenessProbe
- コンテナが正常に稼働しているかどうかを確認する
- 正常に稼働していないと判断された場合、当該Podは再起動される
Probeの構成はこちら
strategy
古いpodを新しいpodに置き換える際の方法。.spec.strategy.typeで指定する。
「Recreate」と「RollingUpdate」の2種類が存在する。
Recreate
存在するpodを直ちにすべて削除する。
RollingUpdate
新しいpodを立て、正常に動くことを確認したあとで古いpodを削除する。
「RollingUpdate」配下で「maxUnavailavle」と「maxSurge」を指定する。
maxUnavailableはアップデート中に使えなくなってもよいpodの数を指定する。
maxSurgeはアップデート中に増えてもいいpodの数を指定する。
整数でしているすることも、%で指定することもできる。
%で指定する場合は、希望する容量(desired pods)を基準にして考える。
どちらも同時に0に設定することはできない。
job
1つ以上のpodを作成し、指定した数のpodが正常終了するまで再試行し続けるリソース。
成功したpodの数を記憶しており、指定した数だけ正常終了するとjobも削除される。
.spec直下でcompletion(job終了条件となるpodの正常終了数)とparallelism(並列実行数)は、podの内容とは関係ないもので、.spec.template.spec配下ではなく.spec配下であることに注意！
apiVersion: batch/v1
kind: Job
metadata:
name: job-pod-failure-policy-example
spec:
completions: 12
parallelism: 3
template:
spec:
restartPolicy: Never
containers:
- name: main
image: docker.io/library/bash:5
command: ["bash"] # example command simulating a bug which triggers the FailJob action
args:
- -c
- echo "Hello world!" && sleep 5 && exit 42
backoffLimit: 6
