本記事は https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests の講座と https://kodekloud.com/ の内容を学習しながら記録したものです。

• 92 Rolling Updates and Rollbacks
• 96 Commands
• 97 Commands and Arguments
• 101 Configuring ConfigMaps in Applications
• 104 Configure Secrets in Applications
• 110 Multi Container Pods
• 114 Init Containers
  • クイズ

92 Rolling Updates and Rollbacks

アプリケーションは継続的に開発され、それに伴いデプロイ戦略も策定する必要があります。運用中のサービスであれば、サービスのダウンタイムをなくすために Recreate よりも Rolling Update 戦略が多く採用されます。新しいバージョンのアプリケーションをデプロイすることをrolloutと呼び、問題が発生した際に戻す作業をrollbackと呼びます。

Kubernetes DeploymentではRolling Update戦略がデフォルトです。

rolloutコマンドを活用すると、Deploymentのrollout履歴を確認できます。

ReplicaSetの場合、新しいReplicaSetを作成し、既存のReplicaSet（Replica Set - 1）のPodを削除しながら、同時に新しいReplicaSet（Replica Set - 2）にPodを起動する方式です。

Rollbackしたい場合は、kubectl rollout undo <deployment name> で元に戻すことができます。

96 Commands

一般的にDockerfileのCMDにプロセスの開始に必要なコマンドを記述します。

docker runコマンドの後に引数を受け取りたい場合は、コマンドパラメータを追加するENTRYPOINTを使用します。以下の例のように、sleepの後の時間は固定ではなく、コンテナ実行時に引数として変更可能です。

引数がない場合はエラーが発生しますが、CMDを定義すれば引数がない場合にデフォルト値で代替され、問題なく実行できるDockerfileを作成できます。また、entrypointはdocker run時に再定義することも可能です。

97 Commands and Arguments

そのDockerfileをKubernetesでPodとして実行する方法は以下の通りです。

混同してはいけない点は、DockerfileのCMDとPod定義のcommandは異なるものだということです。

環境変数を定義するには、以下のようにkey-valueペアを定義できます。

spec:
  containers:
    env:
      - name: APP_COLOR
        value: pink

または、ConfigMapやSecretから環境変数の値を取得することもできます。

101 Configuring ConfigMaps in Applications

ConfigMapとは、その名の通り設定に必要なデータをkey-valueペアで保存したものです。 ConfigMapをimperativeに作成するには以下のようにします。

kubectl create configmap my-config --from-literal=APP_COLOR=blue \
                                   --from-literal=APP_ENV=prod

または、以下のようにdeclarativeに定義することもできます。

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  APP_COLOR: blue
  APP_ENV: prod

ConfigMapは kubectl get configmaps や kubectl describe configmaps コマンドで確認できます。

ConfigMapを使用して環境変数を注入（Inject）するには、envFrom と configMapRef を使用します。

spec:
  containers:
  - name:
    envFrom:
    - configMapRef:
      name: my-config

104 Configure Secrets in Applications

ConfigMapはプレーンテキストをそのまま保存するため、秘密情報の保存には不適切です。暗号化して保存することが重要であり、KubernetesではSecretがその役割を担います。

kubectl create secret generic my-secret --from-literal=DB_Host=mysql
kubectl create secret generic my-secret --from-file=<file_path>

declarativeに保存するには、base64でエンコードして保存する必要があります。

$ echo -n "mysql" | base64
bXlzcWw=

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
data:
  DB_Host: bXlzcWw=

データをデコードするには以下のコマンドを実行します。

$ echo -n 'bXlzcWw=' | base64 --decode
mysql

Secretを通じて環境変数を注入するには、spec.container配下にSecret名を指定します。

envFrom:
  - secretRef:
    name: my-secret

Secretをボリュームとして保存すると、コンテナ内のファイルにSecretのkey-valueがファイル形式で残ります。

Secretは暗号化（encrypted）されたものではありません。単にエンコード（encoded）されただけです。GitHubなどにアップロードしないよう注意が必要です。

110 Multi Container Pods

従来の1つのアプリケーションにすべてが統合されたモノリシックなアーキテクチャとは異なり、マイクロサービスは各機能をサービスとして分離した構造です。

各Pod内でも、ライフサイクルを共有する必要があるコンテナが存在します（例：Log Agent）。そのため、1つのPodに複数のコンテナが実行されるケースもあります。この場合、ライフサイクルだけでなくネットワークやストレージも共有されるため、効率的です。

114 Init Containers

Init Containerは、マルチコンテナPodにおいて、他のコンテナより先に必ず実行されなければならないコンテナを指定する際に使用されます。

spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']

クイズ