kubenetes勉強メモ(Deployment)

# はじめに

kubernetes勉強メモ

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

# Workloadsリソース

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

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

1. Pod
2. Replication Controller
3. Replicaset
4. **deployment**
5. Daemonset
6. Statefulset
7. Job
8. Cronjob



## Deployment

Podの拡張概念。

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

#### ローリングアップデート

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

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

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

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



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

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

## Deploymentを作ってみる

manifestファイルは以下の通り

```yaml
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