はじめに

kubernetes勉強メモ

今回はworkloadsリソースの一つDeploymentについて

Workloadsリソース

クラスタ上にコンテナを起動させるためのリソース。

全部で８種類のリソースがある。

Pod
Replication Controller
Replicaset
deployment
Daemonset
Statefulset
Job
Cronjob

Deployment

Podの拡張概念。

複数のreplicasetを管理することができるやつ。複数管理することでローリングアップデートやロールバックを実現可能にしている。

ローリングアップデート

ローリングアップデートの流れは以下の通り

新しいreplicasetを作る
新しいreplicasetのpodを徐々に増やす
古いreplicasetのpod を徐々に減らす
２、３を繰り替える
古いreplicasetのレプリカ数の０とする

切替する時には注意が必要で

新しいreplicasetでちゃんとコンテナが起動するのか、ヘルスチェックがちゃんと通っているかを確認
replicasetを移行する際のpodの細かい指定　などができる

kubernetesで最も推奨されているコンテナの起動方法

1コンテナ起動するだけでもdeploymentを利用して起動するのが良い！！！

Deploymentを作ってみる

manifestファイルは以下の通り

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment1
spec:
  replicas: 4
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
        - name: nginx-container
          image: nginx:1.12
          ports:
            - containerPort: 80

ほとんどreplicasetのmanifestファイルと変わらないことがわかる。違いと言えば、kindぐらいだ。

でdeploymentを作成する。 --recordオプションをつけることでアップデートしたときの履歴を保持できる。

$ kubectl apply -f deploy.yaml --record

履歴はrelicasetで確認することができる。

$ kubectl get rs -o yaml | head
===== 実行結果 ======
apiVersion: v1
items:
- apiVersion: extensions/v1beta1
  kind: ReplicaSet
  metadata:
    annotations:
      deployment.kubernetes.io/desired-replicas: "4"
      deployment.kubernetes.io/max-replicas: "5"
      deployment.kubernetes.io/revision: "1"
      kubernetes.io/change-cause: kubectl apply --filename=deploy.yaml --record=true

結果より,annotaionsの部分に履歴が保持されていることがわかる。

でdeployment,replicaset,podを確認してみる

$ kubectl get deploy
===== 実行結果 =====
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
deployment1   4/4     4            4           11m

$ kubectl get rs
===== 実行結果 =====
NAME                     DESIRED   CURRENT   READY   AGE
deployment1-7bb5fc6bc6   4         4         4       12m

$ kubectl get po 
===== 実行結果 =====
NAME                           READY   STATUS    RESTARTS   AGE
deployment1-7bb5fc6bc6-5zhnk   1/1     Running   0          13m
deployment1-7bb5fc6bc6-75z8k   1/1     Running   0          13m
deployment1-7bb5fc6bc6-c2kf7   1/1     Running   0          13m
deployment1-7bb5fc6bc6-rc2wv   1/1     Running   0          13m

実行結果よりそれぞれの名前を見てわかる通り

deploymentがreplicasetを作成し、replicasetがpodを作成しているのがわかると思う.

メモ

headコマンド

長いメッセージやテキストファイルの先頭だけを表示するコマンド

コンテナのアップデート

deploymentのコンテナイメージを変更してみる。

今回はnginxのバージョンを1.12→1.13に変更してみるとどうなるかを見てみる。

変更方法は単純で、manifestファイルのngnixのバージョンを変更して,kubectl apply コマンドを実行すれば良い

でreplicasetがどうなっているかを見てみる

$ kubectl get rs
===== 実行結果 =====
NAME                     DESIRED   CURRENT   READY   AGE
deployment1-6d67998cf    4         4         4       2m18s
deployment1-7bb5fc6bc6   0         0         0       19m

このように古いえreplicasetは0となっており,新しいreplicasetが生成されていうのが確認できる。(内部出来にはローリングアップデートがされているらしい。)

ロールバックとは

現在使用しているreplicasetを切り替えること。

今回で言うと,ngnixのバージョンを変えて新しく作成されたreplicasetから古いreplicasetにpodを入れ替えて使えるようにすること。

Deploymentのスケーリング

replicasetと同じで二種類の方法でスケーリングが可能

kubectl scaleコマンドを使用する
kubectl apply -fコマンド

まとめ

Deployment
- workloadsリソースの一つ
- Podの拡張概念。replicasetとほとんど変わらない
- replicasetを作って、podを作る
- podを直接操作しているわけではない
ローリングアップデート
- 古いreplicasetから新しいreplicasetに移行する流れの一種
ロールバック
- 今使っているreplicasetの切替
スケーリング
- kubectl scaleコマンドを使う
- kubectl apply -fコマンドを使う

参考

https://thinkit.co.jp/article/13610?page=0%2C1

kubenetes勉強メモ(Deployment)