Kubernetesの基本コマンド集

## Kubernetesクライアント

KubernetesのAPIと連携するコマンド

### クラスタのステータス

クラスタのバージョンを確認する

```
kubectl version
```

クラスタの診断をする

```
kubectl get componentstatuses
```

### Kubernetesのノードの表示

クラスタ上の全てのノードを表示する

```
kubectl get nodes
```

特定のノードについての詳しい情報をみる

```
kubectl describe nodes node-1
```

### クラスタのコンポーネント

### Kubernetes proxy

proxyのdaemonSetsオブジェクトを確認する

```
kubectl get daemonSets --namespace=kube-system kube-proxy
```

### Kubernetes DNS

DNSのDeploymentオブジェクトを確認する

```
kubectl get deployments --namespace=kube-system kube-dns
```

DNSのServiceオブジェクトを表示する

```
kubectl get services --namespace=kube-system kube-dns
```

## よく使うkubectlコマンド使い方

Kubernetesオブジェクトの操作でよく使うコマンド

### Context

デフォルトのNamespaceを変えるContextを作る

```
kubectl config set-context my-context --namespace=mystuff
```

Contextを切り替える

```
kubectl config use-context my-context
```

### Kubernetes APIオブジェクトの参照

現在のNamespace内のリソースの全てを表示

```
kubectl get <リソース名>
```

特定のリソースを表示

```
kubectl get <リソース名> <オブジェクト名>
```

特定のオブジェクトについて詳しい情報を表示

```
kubectl describe <リソース名> <オブジェクト名>
```

特定の

### Kubernetesオブジェクトの作成・更新・削除

`obj.yml`の設定に基づいてオブジェクトを作成・更新

```
kubectl apply -f obj.yml
```

`obj.yml`に設定されたオブジェクトを削除する

```
kubectl delete -f obj.yml
```

指定したオブジェクトを削除

```
kubectl delete <リソース名> <オブジェクト名>
```

### オブジェクトのLabel

barという名前のPodにcolor=redというラベルをつける

```
kubectl label pods bar color=red
```

barという名前のPodからcolorのラベルを削除する

```
kubectl label pods bar color-
```

### デバッグ用のコマンド

実行中のコンテナのログを見る

```
kubectl logs <Pod名>
```

実行中のコンテナでコマンドをを実行する

```
kubectl exec -it <Pod名> -- bash
```

cpコマンドを使ってコンテナにファイルをコピー・コンテナからファイルをコピー

```
kubectl cp <Pod名>:/path/to/remote/file /path/to/local/file
```


## Pod

Podはいくつかのコンテナをグループ化したもの。
PodはKubernetesが扱うコンテナグループの最小単位

### Podの作成

Podを作成して実行する
動作中のPodのステータスは`kubectl get pods`で見れる

```
kubectl run kuard --image=gcr.io/kuar-demo/kuard-amd64:1
```

Podを削除する

```
kubectl delete deployments/kuard
```

### Podを動かす

```kuard-pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  containers:
    - image: gcr.io/kuard-demo/kuard-amd64:1
      name: kuard
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP
```

上記のymlを用意して、Podを用意する

```
kubectl apply -f kuard-pod.yml
```

### Podの一覧表示

クラスタ内で動いているPodの一覧を取得する

```
kubectl get pods
```

### Podの詳細情報

指定したPodの詳細情報を取得する

```
kubectl describe pods kuard
```

### Podの削除

指定したPodを削除する

```
kubectl delete pods/kuard
```

指定したファイルに基づいてPodを削除する

```
kubectl delete -f kuard-pod.yml
```

### ポートフォワードを使用する

Kubernetesのマスタを経由してローカルホストからアクセスできるようにする
これでlocalhost:8080でアクセスできる

```
kubectl port-forward kuard 8080:8080
```

### ログからの詳細情報の取得

Podのログにアクセスする

```
kubectl logs kuard
```

### execを使用してコンテナ内でコマンド実行

```
kubectl exec kuard date
```

対話的な操作をする

```
kubectl exec -it kaurd ash
```

### コンテナとローカル間でのファイル転送

コンテナからローカルマシンにファイルをコピー

```
kubectl cp <Pod名>:/captures/capture3.txt ./capture3.txt
```

ローカルマシンからコンテナにファイルをコピー

```
kubectl cp $HOME/config.txt <Pod名>:/config.txt
```

### Liveness probe

```kuard-pod-health.yml
apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  containers:
    - image: gcr.io/kuar-demo/kuard-amd64:1
      name: kuard
      livenessProbe:
        httpGet:
          path: /healthy
          port: 8080
        initialDelaySeconds: 5
        timeoutSeconds: 1
        periodSeconds: 10
        failureThreshold: 3
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP
```

上記のymlを用意してPodを用意する
上記以外にも様々なヘルスチェックの種類がある

```
kubectl apply -f kuard-pod-health.yml
```

### リソースの要求

下記のようにリソースの使い方を指定することができる

```kuard-pod-resreq.yml
apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  containers:
    - image: gcr.io/kuar-demo/kuard-amd64:1
      name: kuard
      resources:
        requests:
          cpu: "500m"
          memory: "128Mi"
      ports:
        -containerPort: 8080
         name: http
         protocol: TCP
```

### リソースの制限

```kuard-prod-reslim.yml
apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  containers:
    - image: gcr.io/kuar-demo/kuard-amd64:1
      name: kuard
      resources:
        requests:
          cpu: "500m"
          memory: "128Mi"
        limits:
          cpu: "1000m"
          memory: "256Mi"
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP
```

### VolumeとPodの組み合わせ

```kuard-prod-vol.yml
apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  volumes:
    - name: "kuard-data"
      hostPath:
        path: "/var/lib/kuard"
  containers:
    - image: gcr.io/kuard-demo/kuard-amd64:1
      name: kuard
      volumeMounts:
        - mountPath: "/data"
          name: "kuard-data"
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP
```

### 全てまとめて実行する

```kuard-pod-full.yml
apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  volumes:
    - name: "kuard-data"
      nfs:
        server: my.nfs.server.local
        path: "/exports"
  containers:
    - image: gcr.io/kuar-demo/kuard-amd64:1
      name: kuard
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP
      resources:
        requests:
          cpu: "500m"
          memory: "128Mi"
        limits:
          cpu: "1000m"
          memory: "256Mi"
      volumeMounts:
        - mountPath: "/data"
          name: "kuard-data"
      livenessProbe:
        httpGet:
          path: /healthy
          port: 8080
        initialDelaySeconds: 5
        timeoutSeconds: 1
        periodSeconds: 10
        failureThreshold: 3
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080
        initialDelaySeconds: 30
        timeoutSeconds: 10
        periodSeconds: 10
        failureThreshold: 3
```

## Label

Labelはオブジェクトを識別しグループ化するもの

### Labelの適用

まずLabelをつけたDeployment(Podの集まり)を用意する
alpacaとbandicootというアプリケーションを本番用とテスト用を用意する

```
kubectl run alpaca-prod \
--image=gcr.io/kuar-demo/kuard-amd64:1 \
--replicas=2 \
--labels="ver=1,app=alpaca,env=prod"
```

```
kubectl run alpaca-test \
--image=gcr.io/kuar-demo/kuard-amd64:2 \
--replicas=1 \
--labels="ver=2,app=alpaca,env=test"
```

```
kubectl run bandicoot-prod \
 --image=gcr.io/kuar-demo/kuard-amd64:2 \
--replicas=2 \
--labels="ver=2,app=bandicoot,env=prod"
```

```
kubectl run bandicoot-staging \
--image=gcr.io/kuar-demo/kuard-amd64:2 \
--replicas=1 \
--labels="ver=2,app=bandicoot,env=staging"
```

LabelをつけたDeploymentの一覧を、Label付きで取得する

```
kubectl get deployments --show-labels
```

補足として、作成したDeploymentを全て削除して後片付けしておく

```
kubectl delete deployments --all
```

### Labelの変更

Labelの値を列で見たいときは、`kubectl get`に`-L`オプションをつける

```
kubectl get deployments -L env
```

Labelの値の末尾に`-`をつけると、Labelを削除できる

```
kubectl label deployments alpaca-test 'env-'
```

### Labelセレクタ

全てのPodをラベル付きで一覧表示するときはこう

```
kubectl get pods --show-labels
```

Labelで絞って一覧表示したいときはこう

```
kubectl get pods --selector="ver=2"
```

複数Labelをandで絞り込みたいときはカンマで繋いで指定する

```
kubectl get pods --selector="app=bandicoot,ver=2"
```

あるLabelが複数値のどれかに一致したPodを表示したいときはこう

```
kubectl get pods --selector="app in (alpaca,bandicoot)"
```

あるLabelが設定されているPodを一覧取得したいときはこう

```
kubectl get deployments --selector="env"
```

# Service

Serviceオブジェクトは、PodをグルーピングするLabelを抽象化した概念

### Serviceオブジェクト作成

`kubectl run`でDeploymentを作成し、`kubectl expose`でServiceを作成する

```
kubectl run alpaca-prod \
--image=gcr.io/kuar-demo/kuard-amd64:1 \
--replicas=3 \
--port=8080 \
--labels="ver=1,app=alpaca,env=prod"
```

```
kubectl expose deployment alpaca-prod
```

```
kubectl run bandicoot-prod \
--image=gcr.io/kuar-demo/kuard-amd64:2 \
--replicas=2 \
--port=8080 \
--labels="ver=2,app=bandicoot,env=prod"
```

```
kubectl expose deployment bandicoot-prod
```

Serviceの一覧を取得する

```
kubectl get services -o wide
```

Labelが`app=alpaca`のPodのうち一つ、名前を変数に格納する

```
ALPACA_POD=$(kubectl get pods -l app=alpaca \
-o jsonpath='{.items[0].metadata.name}')
```

先ほどの`app=alpaca`のPod一つを`localhost:48858`でアクセス可能にしてみる

```
kubectl port-forward $ALPACA_POD 48858:8080
```

### Readiness probe

Podがリクエストを受け付けられるかどうかを監視する仕組み
先ほどのDeploymentsにReadiness probeをつけてみる
まずはDeploymentsを編集する

```
kubectl edit deployments/alpaca-prod
```

下記のように編集する
３回連続でチェックに失敗すればPodはリクエストが受けられない状態と判断され、１回でもチェックが通ればリクエストを受けられると判断される

```
spec:
  ...
  template:
    ...
    spec:
      containers:
        ...
        name: alpaca-prod
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          periodSeconds: 2
          initialDelaySeconds: 0
          failureThreshold: 3
          successThreshold: 1
```

Deploymentを再定義するとPodは再作成されるので、改めてport-forwardする

```
ALPACA_POD=$(kubectl get pods -l app=alpaca \
-o jsonpath='{.items[0].metadata.name}')
```

```
kubectl port-forward $ALPACA_POD 48858:8080
```

Readiness probeの動きを観察するには下記が便利

```
kubectl get endpoints alpaca-prod --watch
```

## ReplicaSet

ReplicaSetはPodの数やPodのテンプレートを管理するもの

### ReplicaSetの定義

以下はReplicaSet最小限の定義例

```kuard-rs.yml
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: kuard
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: kuard
        version: "2"
    spec:
      containers:
        - name: kuard
          image: "gcr.io/kuar-demo/kuard-amd64:2"
```

### ReplicaSetの作成

下記コマンドで上記で記述したReplicaSetを作成する

```
kubectl apply -f kuard-rs.yml
```

ReplicaSetが作成されるとPodが作成される

```
kubectl get pods
```

### ReplicaSetの調査

ReplicaSetの状態を調査する場合はこのコマンド

```
kubectl describe rs kuard
```

### PodからのReplicaSetの特定

下記コマンド後にownerReferencesの項目を見ると良い

```
kubectl get pods <Pod名> -o yaml
```

### ReplicaSetに対応するPodの集合の特定

ReplicaSetに対応したPodの集合を得たい場合は`-l`コマンドで絞る

```
kubectl get pods -l app=kuard,version=2
```

### ReplicaSetの手動スケール

ReplicaSetのファイルを設定し直さなくてもPodの数はアドホックに調整できる

```
kubectl scale replicasets kuard --replicas=4
```

設定ファイルを使う場合はReplicaSetを設定するymlファイルの該当項目を下記に書き換える

```
spec:
  replicas: 3
```

ymlファイル書き換え後に設定ファイルを反映させる

```
kubectl apply -f kuard-rs.yml
```

設定が反映されたことを確認する

```
kubectl get pods
```

### ReplicaSetのオートスケール

CPU使用率に対応したオートスケール設定はこう

```
kubectl autoscale rs kuard --min=2 --max=5 --cpu-percent=80
```

オートスケールの設定を確認したいときは`horizontalpodautoscalers`を確認する

```
kubectl get hpa
```

### ReplicaSetの削除

ReplicaSetを削除する

```
kubectl delete rs kuard
```

ReplicaSetが削除されるとPodも削除される

```
kubectl get pods
```

## DaemonSet

ReplicaSetと同様にPodのレプリカを作る仕組み
[ここ](https://thinkit.co.jp/article/13611)がわかりやすい

```
ReplicaSetは、各Kubernetes Node上に合計でx個のPodをNodeのリソース状況に合わせて配置していきます。
そのため、各Node上のPodの数が必ず等しいとも限りませんし、各Node上に確実に配置されるとも限りません。
一方DaemonSetは、全nodeに1 podずつ配置するリソースとなっています。
そのため、レプリカ数などは指定できませんし、2 podずつ配置するといったこともできません。
```

### DaemonSetの作成

クラスタ内のノードのnamespace=kube-system配下にfluentdを仕込む
まずは設定ファイルを用意する

```fluentd.yml
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
  labels:
    app: fluentd
spec:
  template:
    metadata:
      labels:
        app: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd:v0.14.10
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers
```

設定をクラスタに反映させる

```
kubectl apply -f fluentd.yml
```

DaemonSetの状態を見たいときは

```
kubectl describe daemonset fluentd --namespace=kube-system
```

DaemonSetは、全nodeに1 podずつ配置するリソース

```
kubectl get pods -o wide --all-namespaces
```

### Nodeへの配置

特定のLabelがついたNodeにのみDaemonSetを配置する
まずはNodeにLabelを配置する

```
kubectl label nodes docker-for-desktop ssd=true
```

確認

```
kubectl get nodes --show-labels
```

ちなみにLabelを削除したいときはこう

```
kubectl label nodes docker-for-desktop ssd-
```

ここで、DaemonSetを指定したLabelのついたNodeに配置する

```nginx-fast-storage.yml
apiVersion: extensions/v1beta1
kind: "DaemonSet"
metadata:
  name: nginx-fast-storage
  labels:
    app: nginx
    ssd: "true"
spec:
  template:
    metadata:
      labels:
        app: nginx
        ssd: "true"
    spec:
      nodeSelector:
        ssd: "true"
      containers:
        - name: nginx
          image: nginx:1.10.0
```

DaemonSetがちゃんと配置されたか見る

```
kubectl get pods --all-namespaces -o wide
```

## Job

デーモンをたてずにコンテナを実行をするためのオブジェクト

### 一回限りの実行

kubectlを使ってJobを発行する
`--restart=OnFailuer`はkubectlにJobオブジェクトを作成するように支持するオプション

```
kubectl run -i oneshot \
--image=gcr.io/kuar-demo/kuard-amd64:1 \
--restart=OnFailure \
-- --keygen-enable \
   --keygen-exit-on-complete \
   --keygen-num-to-gen 10
```

Jobを削除する

```
kubectl delete jobs oneshot
```

設定ファイルからJobを発行する

```job-oneshot.yml
apiVersion: batch/v1
kind: Job
metadata:
  name: oneshot
  labels:
    chapter: jobs
spec:
  template:
    metadata:
      labels:
        chapter: jobs
    spec:
      containers:
      - name: kuard
        image: gcr.io/kuar-demo/kuard-amd64:1
        imagePullPolicy: Always
        args:
        - "--keygen-enable"
        - "--keygen-exit-on-complete"
        - "--keygen-num-to-gen=10"
      restartPolicy: OnFailure
```

実行する

```
kubectl apply -f job-oneshot.yml
```

Job oneshotを表示する

```
kubectl describe jobs oneshot
```

作成されたPodのログでJobの結果を確認できる

```
kubectl logs oneshot-*****
```

では、Jobの処理が失敗したときの挙動を見てみよう
exit-codeが0以外になるようにして意図的にJobが失敗するように設定する

```job-oneshot-failure1.yml
...
  spec:
    template:
      spec:
        containers:
          ...
          args:
          - "--keygen-enable"
          - "--keygen-exit-one-complete"
          - "--keygen-exit-code=1"
          - "--keygen-num-to-gen=3"
```

上記のJobを改めて発行後にしばらくしたら下記のコマンドを実行

```
kubectl get pods -a -l job-name=oneshot
```

Podの起動リトライが複数実行されていることが確認できる
リトライにリソースを使われないように、リトライごとに再起動の遅延は大きくなる
それでは別の実験をするために一旦該当Jobを削除する

```
kubectl delete jobs oneshot
```

設定ファイルの`restartPolicy`をOnFailureからNeverに変更して、Jobを再起動し、様子を見る

```
kubectl apply -f job-oneshot.yml
```

```
kubectl get pods -a -l job-name=oneshot
```

`restartPolicy`をNeverに設定すると、Podの失敗を検知すると代わりのPodを作成するようになる
ただしこの方法はPodのゴミがNodeの上に際限なく残ってしまうので非推奨

### 閾値分成功するまで並列に実行

Jobを並列実行することができる
`parallelism`で並列数を指定し、`completions`で実行するべき回数を指定する

```job-parallel.yml
apiVersion: batch/v1
kind: Job
metadata:
  name: parallel
  labels:
    chapter: jobs
spec:
  parallelism: 5
  completions: 10
  template:
    metadata:
      labels:
        chapter: jobs
    spec:
      containers:
      - name: kuard
        image: gcr.io/kuar-demo/kuard-amd64:1
        imagePullPolicy: Always
        args:
        - "--keygen-enable"
        - "--keygen-exit-on-complete"
        - "--keygen-num-to-gen=10"
      restartPolicy: OnFailure
```

設定ファイルからJobを実行し、様子をみる

```
kubectl apply -f job-parallel.yml
```

```
kubectl get pods -w
```

## ConfigMap

設定情報を扱うためのオブジェクト

### ConfigMapの作成

下記のような設定用のファイルがあったとする

```my-config.txt
parameter1 = value1
parameter2 = value2
```

上記の設定を内包するConfigMapを作成する

```
kubectl create configmap my-config \
--from-file=my-config.txt \
--from-literal=extra-param=extra-value \
--from-literal=another-param=another-value
```

作成したConfigMapを見る

```
kubectl get configmaps my-config -o yaml
```

### ConfigMapの使用

先に作ったConfigMapを実際に使用してみる
my-configを内包したPodの設定ファイルを作る

```kuard-config.yml
apiVersion: v1
kind: Pod
metadata:
  name: kuard-config
spec:
  containers:
    - name: test-container
      image: gcr.io/kuar-demo/kuard-amd64:1
      imagePullPolicy: Always
      command:
        - "/kuard"
        - "$(EXTRA_PARAM)"
      env:
        - name: ANOTHER_PARAM
          valueFrom:
            configMapKeyRef:
              name: my-config
              key: another-param
        - name: EXTRA_PARAM
          valueFrom:
            configMapKeyRef:
              name: my-config
              key: extra-param
      volumeMounts:
        - name: config-volume
          mountPath: /config
  volumes:
    - name: config-volume
      configMap:
        name: my-config
  restartPolicy: Never
```

Pod設定ファイルを適用

```
kubectl apply -f kuard-config.yml
```

Podを公開する

```
kubectl port-forward kuard-config 8080
```

ブラウザでアクセスすると、ConfigMap経由で追加した環境変数`ANOTHER_PARAM`と`EXTRA_PARAM`が追加されていることが確認できる
また、`my-config.txt`がファイルシステム`/config`にマウントされていることも確認できる

## Secret


ConfigMapに設定できない秘匿情報を管理するオブジェクト

### Secretの作成

ConfigMapでは扱えない機密情報を扱うためのオブジェクト

秘匿ファイルとして下記TLSファイルを用意する

```
curl -o kuard.crt https://storage.googleapis.com/kuar-demo/kuard.crt
curl -o kuard.key https://storage.googleapis.com/kuar-demo/kuard.key
```

`kuard-tls`というSecretオブジェクトを作成する

```
kubectl create secret generic kuard-tls \
--from-file=kuard.crt \
--from-file=kuard.key
```

下記コマンドで詳細を確認する

```
kubectl describe secrets kuard-tls
```

### Secretの使用

上記で作成した`kuard-tls`を`/tls`にマウントしたPodを作る

```kuard-secret.yml
apiVersion: v1
kind: Pod
metadata:
  name: kuard-tls
spec:
  containers:
    - name: kuard-tls
      image: gcr.io/kuar-demo/kuard-amd64:1
      imagePullPolicy: Always
      volumeMounts:
      - name: tls-certs
        mountPath: "/tls"
        readOnly: true
  volumes:
    - name: tls-certs
      secret:
        secretName: kuard-tls
```

```
kubectl apply -f kuard-secret.yml
```

Podを公開する

```
kubectl port-forward kuard-tls 8443:8443
```

`https://localhost:8443`へ警告を無視してアクセスすると、ファイルシステム`/tls`が存在することが確認できる

## プライベートDockerレジストリ

プライベートDockerレジストリ用のSecretオブジェクトを作成する

```
kubectl create secret docker-registry my-image-pull-secret \
--docker-username=<ユーザー名> \
--docker-password=<パスワード> \
--docker-email=<メールアドレス>
```

上記Secretを利用してプライベートDockerレジストリにアクセスする設定ファイルはこう

```kuard-secret-ips.yml
apiVersion: v1
kind: Pod
metadata:
  name: kuard-tls
spec:
  containers:
    - name: kuard-tls
      image: gcr.io/kuar-demo/kuard-amd64:1
      imagePullPolicy: Always
      volumeMounts:
      - name: tls-certs
        mountPath: "/tls"
        readOnly: true
  imagePullSecrets:
    -name: my-image-pull-secret
  volumes:
    - name: tls-certs
      secret:
        secretName: kuard-tls
```


## Deployment

DeploymentはReplicaSetをリリースするための仕組み

### Deployment実行

Podを実行するコマンドは内部的にDeploymentオブジェクトを作成している

```
kubectl run nginx --image=nginx:1.7.12
```

上記コマンドで作成されたDeploymentオブジェクトを確認する

```
kubectl get deployments nginx
```

### Deploymentのスケール


DeploymentはReplicaSetを管理下に置いている
DeploymentがスケールするとReplicaSetもスケールする

```
kubectl scale deployments nginx --replicas=2
```

ReplicaSetの一覧を表示するとスケールされたことが確認できる

```
kubectl get replicasets --selector=run=nginx
```

しかしReplicaSetをスケールダウンを試みてもスケールダウンは実行されない

```
kubectl scale replicasets nginx-1128242161 --replicas=1
```

```
kubectl get replicasets --selector=run=nginx
```

これはDeploymentがReplicaSetを管理下に置いている、トップレベルのオブジェクトであるため

### Deploymentの作成

先ほど作成したDeploymentをディスク上のymlファイルに保存する

```
kubectl get deployments nginx --export -o yaml > nginx-deployment.yml
```

`nginx-deployments.yml`の中身をみるとReplicaSetオブジェクトと中身が似ているが、Podの管理に加えロールアウトの管理をするStrategyオブジェクトをもつ

### Deploymentの管理

先ほどのDeploymentオブジェクトの設定ファイル経由でスケールさせる

```
spec:
  replicas: 3
```

```
kubectl apply -f nginx-deployment.yml
```

スケールしたことを確認する

```
kubectl get deployments nginx
```

設定ファイルを更新してコンテナのイメージを更新する

```
  containers:
  - image: nginx:1.9.10
    imagePullPolicy: Always
```

```
kubectl apply -f nginx-deployment.yml
```

Deploymentを更新すると、新しいバージョンのロールアウトが実行されるので、その様子を見る

```
kubectl rollout status deployments nginx
```

ロールアウトすると旧ReplicaSetと新ReplicaSetが管理下に置かれる

```
kubectl get replicasets -o wide
```

ロールアウトを途中で止めるには下記コマンドを実行する

```
kubectl rollout pause deployments nginx
```

ロールアウト停止中にまたロールアウトを再開したいときは下記コマンドを実行する

```
kubectl rollout resume deployments nginx
```

### ロールアウト履歴

ロールアウトの履歴は下記コマンドで確認できる

```
kubectl rollout history deployments nginx
```

指定リビジョンの詳細を見るには下記コマンド

```
kubectl rollout history deployment nginx --revision=2
```

ロールアウトをロールバックしたいときはこう

```
kubectl rollout undo deployments nginx
```

ReplicaSetのレプリカ数を見るとちゃんとロールアウトとロールバックが実行されていることが確認できる

```
kubectl get replicasets -o wide
```

特定のリビジョンにロールバックしたいときはこう

```
kubectl rollout undo deployments nginx --to-revision=3
```

### Deploymentの削除

```
kubectl delete deployments nginx
```

```
kubectl delete -f nginx-deployments.yml
```

どちらの場合でもDeploymentを削除すると管理下のサービスも削除される