kakakakakku blog

Weekly Tech Blog: Keep on Learning!

kubectl や kube-apiserver など Kubernetes バイナリを checksum で検証する

Kubernetes

以下のドキュメントを読んでいたら kubectl コマンド（バイナリファイル）をダウンロードした後に checksum を使って検証（改ざんなし）をする手順が載っていた．kubectl に限定する必要はなく kube-apiserver などにも適用できる．さっそく試していく！

kubernetes.io

ちなみに Certified Kubernetes Security Specialist (CKS) の出題範囲には「Verify platform binaries before deploying」と書いてあり，内容としては関連していると思う．

github.com

checksum を取得する

checksum (SHA-256) は公開されているため curl コマンドを使って取得できる．例えば kubectl と kube-apiserver を例にすると以下のようになる．最新バージョン（今日時点では v1.22.2）は https://dl.k8s.io/release/stable.txt で確認できるし，具体的にバージョンを指定することもできる．バイナリファイルとしては，他にも kube-scheduler や kubelet や kube-proxy なども指定できる．

  • kubectl コマンド
    • 最新
      • https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256
      • aeca0018958c1cae0bf2f36f566315e52f87bdab38b440df349cd091e9f13f36
    • v1.22.2
      • https://dl.k8s.io/v1.22.2/bin/linux/amd64/kubectl.sha256
      • aeca0018958c1cae0bf2f36f566315e52f87bdab38b440df349cd091e9f13f36
    • v1.20.11
      • https://dl.k8s.io/v1.20.11/bin/linux/amd64/kubectl.sha256
      • 3a2bf981939df89f807858a481f6f5f2e33a7b9708bd029c8bece434db228efe
  • kube-apiserver コマンド
    • 最新
      • https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kube-apiserver.sha256
      • 1887dcff21492cd4fe83682ad22908c8614e732dead927f3af2e5f8fada9a089
    • v1.22.2
      • https://dl.k8s.io/v1.22.2/bin/linux/amd64/kube-apiserver.sha256
      • 1887dcff21492cd4fe83682ad22908c8614e732dead927f3af2e5f8fada9a089
    • v1.20.11
      • https://dl.k8s.io/v1.20.11/bin/linux/amd64/kube-apiserver.sha256
      • bec4c071f6b75b478fd679ec01115f118ba0bcb49131a9011b29a8c53275b3cd

checksum を使って検証をする

以下のように sha256sum --check コマンドを使って検証をすることができる．結果的に OK もしくは WARNING と表示される．

$ curl -LO "https://dl.k8s.io/v1.22.2/bin/linux/amd64/kubectl.sha256"

$ echo "$(<kubectl.sha256) /usr/local/bin/kubectl" | sha256sum --check
kubectl: OK

$ echo "$(<kubectl.sha256) /usr/local/bin/kubectl" | sha256sum --check
/usr/local/bin/kubectl: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

おまけ : macOS で sha256sum コマンドを使う

macOS だと sha256sum コマンドが使えなかった．今回は Homebrew で使えるようにした．

$ which sha256sum
sha256sum not found

$ brew install coreutils

$ which sha256sum
/usr/local/bin/sha256sum

Helmfile で kustomize プロジェクトをデプロイする機能を試した

Kubernetes

Helmfile のドキュメントを読んでいたら Advanced Features として「Deploy Kustomization with Helmfile（Helmfile で kustomize をデプロイする）」という機能が載っていた．最初はどういう意味？と疑問だったけど，簡単に言うと helmfile apply コマンドを使って kustomize プロジェクトをデプロイできる機能だった． 試したことをまとめていく！

github.com

Helmfile で kustomize をデプロイする ☸️

さっそく base/ と overlays/ から構成された通常の kustomize プロジェクトを準備する．今回は kakakakakku/sandbox-kustomize を使う．そして Helmfile の設定ファイルである helmfile.yaml を追加しておく．

$ tree .
.
├── base
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   ├── namespace.yaml
│   └── service.yaml
├── helmfile.yaml
└── overlays
    └── dev
        ├── deployment.yaml
        └── kustomization.yaml

3 directories, 7 files

なお helmfile.yaml は以下のようになる．設定はシンプルで chart に kustomize の overlays ディレクトリを指定している．

releases:
  - name: my-kustomize
    chart: ./overlays/dev/

さっそく helmfile apply コマンドを実行する．なんと簡単に kustomize プロジェクトをデプロイできてしまう🎉もしデプロイはせずにテンプレートを確認する場合は helmfile template コマンドを使えば OK👌

$ helmfile apply

（中略）

UPDATED RELEASES:
NAME           CHART                                                                             VERSION
my-kustomize   /var/folders/tm/whkdv3gd0p17xv63827c4vc00000gr/T/chartify020976714/my-kustomize

$ kubectl get pods -n kakakakakku-dev
NAME                                     READY   STATUS    RESTARTS   AGE
kakakakakku-dev-nginx-7c7bbd5d59-49hfm   2/2     Running   0          80s
kakakakakku-dev-nginx-7c7bbd5d59-54wdd   2/2     Running   0          80s
kakakakakku-dev-nginx-7c7bbd5d59-76wzq   2/2     Running   0          80s
kakakakakku-dev-nginx-7c7bbd5d59-klnrg   2/2     Running   0          80s
kakakakakku-dev-nginx-7c7bbd5d59-rkghp   2/2     Running   0          80s

そして helmfile apply コマンドの結果から確認できる通り，CHART 列に /var/folders/tm/whkdv3gd0p17xv63827c4vc00000gr/T/chartify020976714/my-kustomize と書いてある．ようするに Helmfile は内部的に「一時的な Helm Chart」を作っている．なるほど！仕組みが少し理解できた気がする．

$ cd /var/folders/tm/whkdv3gd0p17xv63827c4vc00000gr/T/chartify410376923/my-kustomize

$ tree .
.
├── Chart.yaml
├── files
│   └── templates
│       └── kustomized.yaml
└── templates
    └── kustomized.yaml

3 directories, 3 files

次の検証に進むため1度消しておく．

$ helmfile delete

（中略）

DELETED RELEASES:
NAME
my-kustomize

Helmfile で Helm Chart と kustomize をデプロイする ☸️

とは言え，kustomize プロジェクトをデプロイするなら普通に kustomize build コマンドを使えば良く，どんなシナリオで便利なのかを考えてみた．例えば Helm Chart と kustomize を併用する場合に便利だと思う．具体的には「Jenkins などミドルウェア関連は Helm Chart」で「自分で実装をしたアプリケーション関連は kustomize」という場合はどうだろうか？そうなると helm コマンドと kustomize コマンドを併用する必要があるけど「helmfile コマンドで統一的に操作できる」という点はメリットになると思う💡

Jenkins を Helm Chart でインストールする例だとすると helmfile.yaml は以下のようになる．

releases:
  - name: my-kustomize
    chart: ./overlays/dev/
  - name: my-jenkins
    chart: jenkins/jenkins
    version: 3.4.1

同じように helmfile apply コマンドを実行すると，なんと Helm Chart も kustomize プロジェクトもデプロイすることができた！便利！

$ helmfile apply

（中略）

UPDATED RELEASES:
NAME           CHART                                                                             VERSION
my-kustomize   /var/folders/tm/whkdv3gd0p17xv63827c4vc00000gr/T/chartify251994092/my-kustomize
my-jenkins     jenkins/jenkins                                                                     3.4.1

helmfile.yaml を簡単に図解すると以下のようになる．

f:id:kakku22:20210927084759p:plain

まとめ ☸️

引き続き Helmfile を試している．今回は kustomize と連携する機能を試した．Helm Chat も kustomize プロジェクトも helmfile コマンドで統一的に操作できるのは便利だと思う．

関連記事 ☸️

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

Helmfile の「テンプレート機能」を試した

Kubernetes

前回の記事では Helmfile に入門した！Helm Chart を宣言的に管理することができて便利だった💡

引き続き Helmfile を試していて，GitHub に載っている「The Helmfile Best Practices Guide」を読んでいたら「テンプレート機能」が紹介されていた．Helmfile で多くの Helm Chart を管理していくと，徐々に helmfile.yaml が長くなる可能性がある．そこで「テンプレート機能」を使って共通化をすることで可読性を高くシンプルに記述できるようになる．さっそく試していく！

github.com

「テンプレート機能」を使わずに Helmfile を記述する

まずは「テンプレート機能」を使わずに Helmfile を記述する．今回はサンプルとして bitnami/metrics-server と bitnami/nginx-ingress-controller を Helm Chart でセットアップする．

artifacthub.io

artifacthub.io

ディレクトリ構成は以下とする．helmfile.yaml と環境ごとに values.yaml を用意する．

$ tree .
.
├── helmfile.yaml
├── metrics-server
│   ├── values-development.yaml
│   ├── values-production.yaml
│   └── values-staging.yaml
└── nginx-ingress-controller
    ├── values-development.yaml
    ├── values-production.yaml
    └── values-staging.yaml

2 directories, 7 files

helmfile.yaml を以下のように記述する．複雑な記述はなく bitnami/metrics-server と bitnami/nginx-ingress-controller を含めている．

environments:
  development:
  staging:
  production:

releases:
  - name: metrics-server
    chart: bitnami/metrics-server
    namespace: kube-system
    version: 5.10.0
    values:
      - metrics-server/values-{{`{{ .Environment.Name }}`}}.yaml
  - name: nginx-ingress-controller
    chart: bitnami/nginx-ingress-controller
    namespace: kube-system
    version: 7.6.21
    values:
      - nginx-ingress-controller/values-{{`{{ .Environment.Name }}`}}.yaml

実際に helmfile apply コマンドを実行するとうまくセットアップできた．

$ helmfile -e staging apply

（中略）

UPDATED RELEASES:
NAME                       CHART                              VERSION
metrics-server             bitnami/metrics-server              5.10.0
nginx-ingress-controller   bitnami/nginx-ingress-controller    7.6.21

$ helmfile delete

「テンプレート機能」を使って Helmfile を書く

今度は「テンプレート機能」を使って Helmfile を記述する．以下のように templates を使って Helm Chart の宣言をテンプレート化できる．今回は chart と namespace と values を含めつつ .Release.Name と .Environment.Name をパラメータとして埋め込むようにしている．そして YAML 自体に実装されているマージ機能 << を使って releases を記述している．

environments:
  development:
  staging:
  production:

templates:
  default: &default
    chart: bitnami/{{`{{ .Release.Name }}`}}
    namespace: kube-system
    values:
      - "{{`{{ .Release.Name }}`}}/values-{{`{{ .Environment.Name }}`}}.yaml"

releases:
- name: metrics-server
  version: 5.10.0
  <<: *default
- name: nginx-ingress-controller
  version: 7.6.21
  <<: *default

結果は同じく helmfile apply コマンドを実行してセットアップすることができた．

$ helmfile -e staging apply

（中略）

UPDATED RELEASES:
NAME                       CHART                              VERSION
metrics-server             bitnami/metrics-server              5.10.0
nginx-ingress-controller   bitnami/nginx-ingress-controller    7.6.21

$ helmfile delete

まとめ

Helmfile で「テンプレート機能」を使うと helmfile.yaml を 共通化して可読性を高くシンプルに記述できるようになる．今回のサンプルでは「18行」→「19行」とむしろ行数が増えてしまったけど，Helm Chart を増やせばメリットが出てくるし，何しろ設定ミスを減らすことにも繋がるため，行数だけでは判断できないと思う．引き続き Helmfile を試していくぞー！

関連記事

kakakakakku.hatenablog.com

Helmfile で Helm Chart を宣言的に管理する

Kubernetes

Helm を使うと Kubernetes クラスタ上に簡単にアプリケーションなどをインストールできる．そして Helm Chart は Artifact Hub で確認できる．また values.yaml と組み合わせれば Helm Chart のデフォルト設定を変更することもできる．しかし helm コマンドを使って実行する場合，以下のようになり「宣言的に」管理できないという課題も残る．今回は Jenkins をサンプルとして使う．

$ helm install my-jenkins jenkins/jenkins --version 3.3.23 -f values.yaml

artifacthub.io

Helmfile とは ⎈

そこで Helmfile を紹介する💡Helmfile を使うと helm コマンドを実行するときの設定を YAML で「宣言的に」管理できるようになる．現在もアクティブ開発されていて利用実績も多そう．今回は Helmfile を試していく！

github.com

前提として helmfile コマンドを準備しておく．今回は Homebrew を使う．また helmfile diff コマンドを使うこともあるため helm-diff も追加でインストールしておく．それにしても v0.140 ってスゴイ👀

$ brew install helmfile
$ helm plugin install https://github.com/databus23/helm-diff

$ helmfile version
helmfile version v0.140.0

Helmfile に入門する ⎈

Helmfile では，以下のように helmfile.yaml を作るところから開始する．helm コマンド的には helm install my-jenkins jenkins/jenkins --version 3.3.23 -f values.yaml と同じ意味になる．サンプルとして values.yaml も載せておく．今回は serviceType と servicePort を変更する．

📁 helmfile.yaml

releases:
  - name: my-jenkins
    chart: jenkins/jenkins
    version: 3.3.23
    values:
      - values.yaml

📁 values.yaml

controller:
  serviceType: NodePort
  servicePort: 8888

さっそく helmfile apply コマンドを使って Helm Chart をインストールする．

$ helmfile apply

（中略）

UPDATED RELEASES:
NAME         CHART             VERSION
my-jenkins   jenkins/jenkins    3.3.23

すぐに Jenkins にアクセスできるようになる．画面右下に書いてある通り Jenkins 2.289.1 になっていた．

f:id:kakku22:20210908202659p:plain

Helm Chart を更新する ⎈

次に Helm Chart を更新する．以下のように helmfile.yaml で version: 3.3.23 → version: 3.4.1 にする．

releases:
  - name: my-jenkins
    chart: jenkins/jenkins
    version: 3.4.1
    values:
      - values.yaml

実行をする前に helmfile diff コマンドを使って差分を確認することもできる．今回はバージョン間の差が少なかった．

$ helmfile diff
Comparing release=my-jenkins, chart=jenkins/jenkins

（中略）

default, my-jenkins, StatefulSet (apps) has changed:
  # Source: jenkins/templates/jenkins-controller-statefulset.yaml
  apiVersion: apps/v1
  kind: StatefulSet
  metadata:
    name: my-jenkins
    namespace: default
    labels:
      "app.kubernetes.io/name": 'jenkins'
-     "helm.sh/chart": "jenkins-3.3.23"
+     "helm.sh/chart": "jenkins-3.4.1"
      "app.kubernetes.io/managed-by": "Helm"
      "app.kubernetes.io/instance": "my-jenkins"
      "app.kubernetes.io/component": "jenkins-controller"

（中略）

もう1度 helmfile apply コマンドを実行するとすぐに更新される！簡単！

$ helmfile apply

（中略）

UPDATED RELEASES:
NAME         CHART             VERSION
my-jenkins   jenkins/jenkins     3.4.1

1度削除をしておく．

$ helmfile delete

DELETED RELEASES:
NAME
my-jenkins

Helmfile で複数環境を作る ⎈

もう少し Helmfile の良さを試していく．Helmfile では production や staging など「複数環境」を作ることができる．helmfile.yaml に以下のように environments を設定して {{ .Environment.Name }} で参照することができる．

📁 helmfile.yaml

environments:
  development:
  staging:
  production:

releases:
  - name: my-jenkins
    chart: jenkins/jenkins
    version: 3.4.1
    values:
      - values-{{ .Environment.Name }}.yaml

そして values-production.yaml や values-staging.yaml など，環境ごとに values.yaml を用意しておく．今回試す values-staging.yaml では servicePort を 8889 に変えた．

$ tree .
.
├── helmfile.yaml
├── values-development.yaml
├── values-production.yaml
└── values-staging.yaml

0 directories, 4 files

📁 values-staging.yaml

controller:
  servicePort: 8889

さっそく -e オプションを使って staging 環境を作る．指定した通り servicePort も 8889 になっている．便利！

$ helmfile -e staging apply

（中略）

UPDATED RELEASES:
NAME         CHART             VERSION
my-jenkins   jenkins/jenkins     3.4.1

$ kubectl describe services my-jenkins | egrep '^Port:'
Port:              http  8889/TCP

まとめ ⎈

今回は Helmfile に入門した．Helmfile にはまだ他にも機能があるため引き続き試していくぞー！

github.com

Deployment の maxUnavailable と maxSurge : ロールアウト中の割合を設定する

Kubernetes

Kubernetes で Deployment を使うと Pod を安全にデプロイ（ロールアウト）できる．そのときに更新する Pod の割合として Max Unavailable と Max Surge という設定値があり，デフォルト値は以下のようにドキュメントに書いてある．今回は動作確認をしながら図解もしていく．

  • Max Unavailable（停止状態になる最大 Pod 数）
    • .spec.strategy.rollingUpdate.maxUnavailable
    • デフォルト値 : 25%（小数点切り捨て）
    • 値には 絶対値 or % を設定できる
  • Max Surge（宣言した Pod 数を超えて作れる Pod 数）
    • .spec.strategy.rollingUpdate.maxSurge
    • デフォルト値 : 25%（小数点切り上げ）
    • 値には 絶対値 or % を設定できる

kubernetes.io

デフォルト値を確認する

以下の Deployment (replicas: 10) を適用する． Max Unavailable と Max Surge のデフォルト値である 25% を考慮すると 7.5 ~ 12.5 となるため，デプロイ時には「最低 8 Running Pod」と「最高 13 Pod」になると期待できる．さっそく以下の Deployment で images を nginx:1.19-alpine から nginx:1.20-alpine に更新してデプロイをする．

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sandbox-rolling-update
  labels:
    app: sandbox-rolling-update
spec:
  replicas: 10
  selector:
    matchLabels:
      app: sandbox-rolling-update
  template:
    metadata:
      labels:
        app: sandbox-rolling-update
    spec:
      containers:
      - name: nginx
        image: nginx:1.19-alpine
        ports:
          - containerPort: 80

更新中の Pod の状態を確認すると以下のようになる．「10 Running Pod」から「8 Running Pod と 5 ContainerCreating Pod」になった．期待通りの挙動となる．

$ kubectl get pods -l app=sandbox-rolling-update --sort-by=.status.phase
NAME                                      READY   STATUS    RESTARTS   AGE
sandbox-rolling-update-59c54649f5-4p2ds   1/1     Running   0          20s
sandbox-rolling-update-59c54649f5-6gfps   1/1     Running   0          20s
sandbox-rolling-update-59c54649f5-97cvh   1/1     Running   0          20s
sandbox-rolling-update-59c54649f5-b4sl2   1/1     Running   0          20s
sandbox-rolling-update-59c54649f5-crnnc   1/1     Running   0          20s
sandbox-rolling-update-59c54649f5-h5l8q   1/1     Running   0          20s
sandbox-rolling-update-59c54649f5-jkcjk   1/1     Running   0          20s
sandbox-rolling-update-59c54649f5-jnwwr   1/1     Running   0          20s
sandbox-rolling-update-59c54649f5-t746f   1/1     Running   0          20s
sandbox-rolling-update-59c54649f5-vdpkq   1/1     Running   0          20s

$ kubectl get pods -l app=sandbox-rolling-update --sort-by=.status.phase
NAME                                      READY   STATUS              RESTARTS   AGE
sandbox-rolling-update-5d4d5d6884-wkrb8   0/1     ContainerCreating   0          0s
sandbox-rolling-update-5d4d5d6884-sg8zc   0/1     ContainerCreating   0          0s
sandbox-rolling-update-5d4d5d6884-fkmdm   0/1     ContainerCreating   0          0s
sandbox-rolling-update-5d4d5d6884-bv9s6   0/1     ContainerCreating   0          0s
sandbox-rolling-update-5d4d5d6884-bdbsx   0/1     ContainerCreating   0          0s
sandbox-rolling-update-59c54649f5-t746f   1/1     Running             0          60s
sandbox-rolling-update-59c54649f5-jnwwr   1/1     Running             0          60s
sandbox-rolling-update-59c54649f5-vdpkq   1/1     Running             0          60s
sandbox-rolling-update-59c54649f5-h5l8q   1/1     Running             0          60s
sandbox-rolling-update-59c54649f5-crnnc   1/1     Running             0          60s
sandbox-rolling-update-59c54649f5-b4sl2   1/1     Running             0          60s
sandbox-rolling-update-59c54649f5-97cvh   1/1     Running             0          60s
sandbox-rolling-update-59c54649f5-6gfps   1/1     Running             0          60s

流れを簡単に図解してみた🎨

f:id:kakku22:20210901222813p:plain

maxUnavailable と maxSurge を指定する

次に .spec.strategy.rollingUpdate.maxUnavailable: 0% と .spec.strategy.rollingUpdate.maxSurge: 100% を追加する．そして nginx:1.20-alpine を nginx:1.21-alpine に更新してデプロイをする．ようするに「最低 10 Running Pod」を維持しつつ「最高 20 Pod」まで許容する．リソースは2倍必要になるけどパフォーマンスを落とすことなくデプロイできる．

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sandbox-rolling-update
  labels:
    app: sandbox-rolling-update
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0%
      maxSurge: 100%
  selector:
    matchLabels:
      app: sandbox-rolling-update
  template:
    metadata:
      labels:
        app: sandbox-rolling-update
    spec:
      containers:
      - name: nginx
        image: nginx:1.21-alpine
        ports:
          - containerPort: 80
      terminationGracePeriodSeconds: 0

更新中の Pod の状態を確認すると以下のようになる．「10 Running Pod」から「10 Running Pod と 10 ContainerCreating Pod」になった．期待通りの挙動となる．

$ kubectl get pods -l app=sandbox-rolling-update --sort-by=.status.phase
NAME                                      READY   STATUS    RESTARTS   AGE
sandbox-rolling-update-5d4d5d6884-56q4g   1/1     Running   0          8m31s
sandbox-rolling-update-5d4d5d6884-8d5gk   1/1     Running   0          8m30s
sandbox-rolling-update-5d4d5d6884-8sf46   1/1     Running   0          8m31s
sandbox-rolling-update-5d4d5d6884-bdbsx   1/1     Running   0          8m33s
sandbox-rolling-update-5d4d5d6884-bv9s6   1/1     Running   0          8m33s
sandbox-rolling-update-5d4d5d6884-fkmdm   1/1     Running   0          8m33s
sandbox-rolling-update-5d4d5d6884-hlzfp   1/1     Running   0          8m31s
sandbox-rolling-update-5d4d5d6884-sg8zc   1/1     Running   0          8m33s
sandbox-rolling-update-5d4d5d6884-wkrb8   1/1     Running   0          8m33s
sandbox-rolling-update-5d4d5d6884-z68nq   1/1     Running   0          8m31s

$ kubectl get pods -l app=sandbox-rolling-update --sort-by=.status.phase
NAME                                      READY   STATUS              RESTARTS   AGE
sandbox-rolling-update-59c54649f5-4dzbg   0/1     ContainerCreating   0          5s
sandbox-rolling-update-59c54649f5-5twh4   0/1     ContainerCreating   0          5s
sandbox-rolling-update-59c54649f5-8gqkt   0/1     ContainerCreating   0          5s
sandbox-rolling-update-59c54649f5-btcsd   0/1     ContainerCreating   0          5s
sandbox-rolling-update-59c54649f5-cf8mc   0/1     ContainerCreating   0          5s
sandbox-rolling-update-59c54649f5-dmmrq   0/1     ContainerCreating   0          5s
sandbox-rolling-update-59c54649f5-l7nmj   0/1     ContainerCreating   0          5s
sandbox-rolling-update-59c54649f5-pbwl5   0/1     ContainerCreating   0          5s
sandbox-rolling-update-59c54649f5-s8dwc   0/1     ContainerCreating   0          5s
sandbox-rolling-update-59c54649f5-x6hfz   0/1     ContainerCreating   0          5s
sandbox-rolling-update-5d4d5d6884-56q4g   1/1     Running             0          8m46s
sandbox-rolling-update-5d4d5d6884-8d5gk   1/1     Running             0          8m45s
sandbox-rolling-update-5d4d5d6884-8sf46   1/1     Running             0          8m46s
sandbox-rolling-update-5d4d5d6884-bdbsx   1/1     Running             0          8m48s
sandbox-rolling-update-5d4d5d6884-bv9s6   1/1     Running             0          8m48s
sandbox-rolling-update-5d4d5d6884-fkmdm   1/1     Running             0          8m48s
sandbox-rolling-update-5d4d5d6884-hlzfp   1/1     Running             0          8m46s
sandbox-rolling-update-5d4d5d6884-sg8zc   1/1     Running             0          8m48s
sandbox-rolling-update-5d4d5d6884-wkrb8   1/1     Running             0          8m48s
sandbox-rolling-update-5d4d5d6884-z68nq   1/1     Running             0          8m46s

流れを簡単に図解してみた🎨

f:id:kakku22:20210901222833p:plain

まとめ

今回は Deployment に設定できる Max Unavailable と Max Surge の挙動を試した．ドキュメントを読むだけでも把握できるけど，やっぱり実際に試すと理解が深まる．今後も手を動かすことを意識していくぞー💪