記事ディレクトリ

1. 背景
- 1.1 物理マシン、仮想マシン、コンテナ化の時代
- 1.2 コンテナオーケストレーションの必要性
2. K8S アーキテクチャ
- 2.2 ワーカーノード
3. 中心となる概念
4.K8Sのインストール
5. kubectlの共通コマンド
6.K8S実戦
参考文献

1. 背景

1.1 物理マシン、仮想マシン、コンテナ化の時代

K8S を紹介する前に、物理マシン時代、仮想マシン時代、コンテナ化時代というサーバーの進化プロセスを見てみましょう。

物理マシン時代の欠点:

導入に時間がかかる: 各サーバーには、オペレーティングシステム、関連アプリケーションに必要な環境、およびさまざまな構成をインストールする必要があります。
高コスト: 物理サーバーは非常に高価です
リソースの無駄: ハードウェアリソースを十分に活用できない
拡張と移行のコストが高い: 拡張と移行には、まったく同じ環境の再構成が必要です

仮想マシン時代は、物理マシン時代の欠点を解決したものであり、仮想マシン時代の特徴は次のとおりです。

導入が簡単: 各物理マシンは複数の仮想マシンを導入でき、テンプレートを使用して迅速な導入と低コストを実現できます。
リソースプール: 開かれた仮想マシンは、サーバーのパフォーマンスを最大限に引き出すバックアップリソースプールとして使用できます。
リソースの分離: 各仮想マシンにはメモリディスクなどのハードウェアリソースが個別に割り当てられており、仮想マシンは相互に影響を与えません。
拡張が簡単: 仮想マシンはいつでも物理マシン上で作成または破棄できます。

仮想マシンの欠点は、各仮想マシンにオペレーティングシステムをインストールする必要があることです。

コンテナ化の時代は仮想マシン時代の欠点を解決し、仮想マシン時代の利点を引き継ぎながら、コンテナ化の時代には次のような利点もあります。

ハードウェアリソースのより効率的な使用: すべてのコンテナはホストオペレーティングシステムカーネルを共有するため、オペレーティングシステムをインストールする必要はありません。
一貫した実行環境: 同じイメージが同じ動作を生成します。
小さい: オペレーティングシステムをパッケージ化する必要がないため、コンテナーイメージは仮想マシンよりも小さくなります。
高速: コンテナは数秒で起動できます。これは基本的にホスト上のプロセスです。

1.2 コンテナオーケストレーションの必要性

コンテナ技術の代表格であるdockerですが、Dockerは単体マシンでは高速で便利ですが、クラスタではどうなるのでしょうか？5 つのノードがあり、各ノードに docker がインストールされていると仮定し、10 個のコピーが必要なアプリケーションをデプロイしたいとします。その方法は次のとおりです。

5 つのノードにランダムに分散
均等に分散され、各ノードに 2 が割り当てられます。
分散は各ノードの負荷状況に基づいて行われ、負荷の低いノードが優先されます。

どちらの方法を選択しても、同じ docker run コマンドを 10 回実行する必要があり、最後の方法の場合は、各ノードの負荷を 1 つずつ確認する必要があり、この問題は自動ボックス化に寄与しないと呼ばれます。

今後 1 部追加する場合は上記の操作を繰り返す必要がありますが、10 部追加する場合はどうなるでしょうか? 100足したらどうでしょうか？手動で操作するのは少し不快ですが、この問題を横伸縮不良、略して横伸縮と呼びます。

今すぐバージョンを変更する場合、更新またはロールバックする場合は、コンテナーを停止し、新しいバージョンのイメージを置き換えてから、再度開始する必要があります。この操作は、コピーごとに 1 回実行する必要があります。コピーが多すぎる場合は、この問題は、好ましくない自動ロールアウトとロールバックと呼ばれます。

コンテナーが実行を停止した場合、Docker の再起動戦略によりコンテナーが引き上げられ、実行が継続されます。これは問題ありません。ノードがダウンした場合はどうなりますか? 上記のコンテナがすべて停止し、docker restart 戦略が役に立たないため、コピー数が減少します。この問題は、自己修復不能と呼ばれます。

ロードバランシングが必要であると仮定すると、ロードバランサーをインストールするために新しいノードを追加し、5 つのノードの IP とポートを設定する必要があります。前提として、コンテナーのポートがホストポートにマッピングされ、ネットワークがロードバランサーの前にマッピングされている必要があります。コンテナは分離されており、相互にアクセスできませんメンテナンスコストが高く、この問題はサービスの検出や負荷分散に役立ちません。

上記の操作はコンテナオーケストレーションです。上記の問題があるため、オーケストレーションを自動化する技術が必要です。この技術が K8S です。K8S はkubernetes /kjubɚ'nɛtɪs/

Kubernetes は、産業グレードのコンテナオーケストレーションプラットフォームです。Kubernetes という言葉はギリシャ語で、その中国語訳は「操舵手」または「パイロット」です。また、一部の一般的な情報には「ks」という単語も表示されます。つまり、「K8s」という単語は、8 文字の「ubernete」を「8」に置き換えた略語です。

K8S 公式サイト：https://kubernetes.io/zh-cn/
公式サイトの説明によると、以下の機能を持っています。
ここに画像の説明を挿入します

2. K8S アーキテクチャ

K8S では、クラスタはマスターコントロールノードとワーカーノードで構成され、全体的なアーキテクチャは次の図に示されています。

## 2.1 マスターノード

etcd: Raft プロトコルを使用した分散 KV データベース。関連データをクラスターに保存するために使用されます。プロジェクトアドレス: https://github.com/etcd-io/etcd
API サーバー: クラスターへの統合された入り口であり、Restful スタイルで操作され、ストレージ用に etcd に引き渡されます (etcd にアクセスできる唯一のコンポーネント)。認証、認可、アクセス制御、API 登録および検出などのメカニズムを提供します。 kubectl コマンドラインツール、ダッシュボード視覚化パネル、または SDK などのアクセスを通じて使用できます。
スケジューラ: ノードのスケジューリング、ノードノードアプリケーションのデプロイメントの選択。
コントローラマネージャ: クラスタ内の通常のバックグラウンドタスクを処理し、1 つのリソースが 1 つのコントローラに対応し、クラスタのステータスを監視して実際のステータスが最終ステータスと一致していることを確認します。

2.2 ワーカーノード

kubelet: ローカルコンテナを管理し、データを API サーバーに報告するためにノードノード代表に送信されるマスターに相当します。
コンテナランタイム: コンテナランタイム、K8S は複数のコンテナランタイム環境をサポートします: Docker、Containerd、CRI-O、Rktlet、および Kubernetes CRI (コンテナランタイム環境インターフェイス) を実装するソフトウェア
kube-proxy: サービス (Service) 抽象コンポーネントを実装し、PodIP の変更とロードバランシングをシールドします。

3. 中心となる概念

3.1 ポッド

ポッドは最小のスケジューリング単位です
ポッドには 1 つ以上のコンテナ (コンテナ) が含まれます
ポッド内のコンテナはストレージとネットワークを共有し、ローカルホスト経由で通信できます。

Pod とは元々 Wandoujia のことで、ここでは K8S におけるリソーススケジューリングの最小単位を指します。Wandoujia 内の小さな Bean はコンテナのようなもので、Wandoujia 自体がポッドのようなものです。

3.2 導入

デプロイメントは Pod 抽象化の上位レベルの抽象化であり、Pod のセットのコピー数とこの Pod のバージョンを定義できます。一般に、ユーザーはアプリケーションの実際の管理を行うために Deployment 抽象化を使用します。Pod は Deployment を構成する最小単位です。

ポッドのセットのレプリカ、バージョンなどの数を定義します。
コントローラーによって維持されるポッドの数
障害が発生したポッドを自動的に復元する
指定されたポリシーを持つコントローラーを通じてバージョンを制御する

3.3 サービス

ポッドは不安定であり、IP が変更されるため、この変更を保護するために抽象化レイヤーが必要です。この抽象化レイヤーはサービスと呼ばれます。

1 つ以上の Pod インスタンスに安定したアクセスアドレスを提供する
複数のアクセス方法をサポート ClusterIP (クラスター内でのアクセス) NodePort (クラスター外でのアクセス) LoadBalancer (クラスター外での負荷分散)

3.4 ボリューム

ボリュームはストレージボリュームです。ファイルシステムにアクセスするために、ポッド内でボリュームを宣言できます。同時に、ボリュームは抽象化レイヤーでもあります。その特定のバックエンドストレージには、ローカルストレージ、NFS ネットワークストレージ、クラウドストレージ ( Alibaba Cloud Disk、AWS Cloud Disk、Google Cloud Disk など)、分散ストレージ (ceph、GlusterFS など)

ポッド内のコンテナにアクセスできるファイルシステムを宣言します。
ポッド内の 1 つ以上のコンテナの指定されたパスの下にマウントできます
複数のバックエンドストレージをサポート

3.5 名前空間

Namespace (コマンド空間) は、リソースを論理的に分離するために使用されます。たとえば、上記の Pod、Deployment、Service はすべてリソースです。異なる Namespace の下にあるリソースは同じ名前を持つことができます。同じ名前空間内のリソース名は一意である必要があります

クラスター内の論理分離メカニズム (認証、リソースなど)
すべてのリソースは名前空間に属します
同じ名前空間内のリソース名は一意です
異なる名前空間のリソースは同じ名前を持つことができます

4.K8Sのインストール

特定のインストールチュートリアルについては、https: //kuboard.cn/install/install-k8s.html
を参照してください。これは非常に詳細であるため、ここでは繰り返しません。簡略化されたプロセスは次のとおりです。

2 つ以上の仮想マシンを作成します
オペレーティングシステムは CentOS 7.8 または CentOS Stream 8 です。
各ノードの CPU コア数は 2 以上、メモリは 4G 以上 (テスト済みの 2G も許容されます)
ネットワーク構成ファイルを変更します: /etc/sysconfig/network-scripts/ifcfg-ens33 が固定 IP に変更されます。
containerd/kubelet/kubeadm/kubectl をインストールします。チュートリアルで使用されるコンテナーランタイムは、containerd であることに注意してください。docker を使用する必要がある場合は、最初に docker をインストールし、スクリプトでの containerd のインストールをスキップできます。
マスターノードの初期化
ワーカーノードの初期化
確認: マスターノードで kubectl get Nodes -o Wide を実行し、追加されたワーカーノードが確認できればインストール成功です。

私の環境は以下の通りです。

NAME        STATUS   ROLES                  AGE   VERSION   INTERNAL-IP       
my-master   Ready    control-plane,master   27h   v1.21.0   192.168.108.101
my-node     Ready    <none>                 27h   v1.21.0   192.168.108.102

192.168.108.101 は my-master という名前のマスターロール、192.168.108.102 は my-node という名前のワーカーロールです。

5. kubectlの共通コマンド

kubectl は、Kubernetes クラスターを管理するための Kubernetes コマンドラインツールです。

kubectl は Kubernetes クラスターマネージャーを制御します。K8S
クラスター管理のコントローラーを意味します。kubectl --help はヘルプコマンドを出力できます。

(1) クラスター情報を表示します。

kubectl cluster-info  # 显示集群信息。

(2) リソースのステータスを確認します。

kubectl get pods  # 查看所有Pod的状态
kubectl get deployments  # 查看所有部署的状态
kubectl get services  # 查看所有服务的状态
kubectl get nodes  # 查看所有节点的状态
kubectl get namespaces  # 查看所有命名空间的状态

kubectl describe pod <pod-name>  # 显示特定Pod的详细信息
kubectl describe node <node-IP/name>  # 显示特定Node的详细信息

(3) リソースの作成と管理:

kubectl create -f <filename>  # 根据YAML文件创建资源
kubectl apply -f <filename>  # 根据YAML文件创建或更新资源
kubectl delete -f <filename>  # 根据YAML文件删除资源

kubectl scale deployment <deployment-name> --replicas=<replica-count>  # 扩展或缩减部署的副本数
kubectl expose deployment <deployment-name> --port=<port> --type=<service-type>  # 创建一个服务来公开部署

(4) 操作を実行します。

kubectl exec -it <pod-name> -- <command>  # 在Pod中执行特定命令
kubectl logs <pod-name>  # 查看Pod的日志
kubectl port-forward <pod-name> <local-port>:<pod-port>  # 将本地端口与Pod的端口进行转发

(5) リソースを削除します。

kubectl delete deployment <deployment-name>  # 删除部署
kubectl delete pod <pod-name>  # 删除Pod
kubectl delete service <service-name>  # 删除服务

6.K8S実戦

6.1 水平方向の拡張

なぜ最初に実際の容量を拡張するのでしょうか? これが最も簡単なので、まず一般的な nginx をデプロイします

kubectl create deployment web --image=nginx:1.14

この文はリソースを作成することを意味します。リソースは何ですか? これは Web という名前のデプロイメント (デプロイと省略できます) であり、イメージが nginx バージョン 1.14 であることを指定しますが、この文はまだ実行しないでください。再利用が難しいため、通常はこの方法でアプリケーションをデプロイしません。通常、これは yaml ファイルを介して行われます。デプロイメントは次のように行われます。

kubectl create deployment web --image=nginx:1.14 --dry-run -o yaml > web.yaml

–dry-run は試運転の意味で、動作するか試してみますが動作しません。
-o yaml は yaml 形式での出力を意味します
web.yaml は、出力コンテンツを web.yaml ファイルにリダイレクトすることを意味します

実行後、web.yaml ファイルの内容を確認してください。

apiVersion: apps/v1        # 表示资源版本号为apps/v1 
kind: Deployment           # 表示这是一个Deployment
metadata:                  # 一些元数据信息
  creationTimestamp: null
  labels:                  # 标签，可以随便定义
    app: web
  name: web                # 这个资源的名字
spec:                      # 资源的描述或者规格
  replicas: 1              # 副本数量
  selector:                # 选择器
    matchLabels:           # 需要匹配的标签
      app: web             # 标签的具体键值对
  strategy: {
    
    }
  template:                # 模板。表示Pod的生成规则
    metadata:
      creationTimestamp: null
      labels:
        app: web
    spec:                  
      containers:
      - image: nginx:1.14  #指定镜像文件
        name: nginx
        resources: {
    
    }
status: {
    
    }

次のコマンドを使用して web.yaml を適用します。web.yaml はデプロイメントとポッドを宣言します。

kubectl apply -f web.yaml

実行後、次のコマンドを使用してデプロイメントとポッドを表示できます。

kubectl get deploy,po -o wide

結果は次のとおりです。

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES       SELECTOR
deployment.apps/web   1/1     1            1           2m40s   nginx        nginx:1.14   app=web

NAME                       READY   STATUS    RESTARTS   AGE     IP               NODE    ...
pod/web-5bb6fd4c98-lg555   1/1     Running   0          2m40s   10.100.255.120   my-node ...

リソースが確立され、ワーカーノードで実行されていることがわかります。ポッドの IP にアクセスしてみます。

curl 10.100.255.120

nginx からの次の標準の戻り値は、アプリケーションがデプロイされていることを示します。

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
</html>

この作業はかなり面倒だと思いますか? yaml ファイルはまだ長いです。頭を使わずに Docker を実行して実行する方がよいでしょう。心配しないでください。後で拡大したり縮小したりすると、その威力がわかります。もちろん、あなたはkubectl createdeploymentweb --image=nginx:1.14 を実行するコマンド。テストは問題ありませんが、運用環境ではこれを強くお勧めしません。

[実際の拡張] : 容量拡張の需要が来て、同じ nginx のコピーを 10 個展開する必要があるとします。どうすればよいでしょうか? K8S では非常に簡単で、「10 部欲しい」と伝えるだけで、その他の細かいことは気にする必要はありません。

具体的な方法は、上記のweb.yamlファイルを修正し、replicas:1からreplicas:10を宣言し、最後に適用するというものです。

kubectl apply -f web.yaml

この時点で、すぐに kubectl get po を実行すると、一部のコンテナーが実行を開始し、一部は作成中、一部はまだ保留中であることがわかります。

NAME                       READY   STATUS              RESTARTS   AGE
pod/web-5bb6fd4c98-52qmf   0/1     ContainerCreating   0          1s
pod/web-5bb6fd4c98-5sp5l   0/1     Pending             0          1s
pod/web-5bb6fd4c98-9t2hm   0/1     ContainerCreating   0          1s
pod/web-5bb6fd4c98-lg555   1/1     Running             0          11m
...

すべてのポッドが実行状態になるまでしばらく待ちます。もちろん、面倒になってワンクリックで容量を拡張することもできます。

kubectl scale deploy web --replicas=10

6.2 自動ボクシング

可用性に影響を与えることなく、リソースのニーズやその他の制約に基づいてコンテナを自動的に配置します。クリティカルなサービスワークロードとベストエフォート型のサービスワークロードを組み合わせて、リソースの使用率を向上させ、より多くのリソースを節約します。

K8S は、ノードテイント、ノードラベル、ポッドスケジューリング戦略などを含む複数の戦略をサポートします。目的は、最大限の柔軟性を提供し、最終的には全体的なリソース使用率 (オートボックス化) を向上させることです。

6.2.1 ノード汚染

テイントテイント: ノードは通常の割り当てとスケジューリングを実行しません。これはノード属性であり、3 つの属性値があります。

NoSchedule: スケジュールを設定してはなりません
PreferNoSchedule: スケジュールされないようにします (スケジュールされる可能性もあります)
NoExecute: スケジュールを設定せず、ノードの既存のポッドも削除します。

つまり、ノードが汚染されている場合、スケジューリング中に上記の属性に従ってスケジュールされます。一般に、マスターノードのテイント値は NoSchedule です。マスターテイント値を確認してください。

kubectl describe node my-master | grep Taints

次の出力が表示されます

Taints:             node-role.kubernetes.io/master:NoSchedule

6.2.2 ポッドのスケジューリング戦略

ポッドのスケジューリングポリシーは、ポッドが最終的にどのノードにスケジュールされるかに影響します。ポッドのスケジューリングポリシーには、次の 3 種類があります。

ポッドによって宣言されたリクエストと制限。前者はポッドが必要とするリソースの数を示し、後者はポッドが最大で使用するリソース (CPU メモリなど) の数を示します。
ノードラベルセレクター。スケジュール用のラベルに一致するノードを選択します。
ノードアフィニティはハードアフィニティとソフトアフィニティに分けられ、前者は満たされる必要があり、後者は満たされるよう努めますが、必須ではありません

6.3 秘密

Secret は秘密という意味ですが、K8S ではどういう意味ですか? K8S では、etcd に保存された構成を表します。この構成は秘密で安全で、通常は Base64 でエンコードされます。この構成は、ボリュームまたは環境変数をマウントすることで Pod からアクセスできます。最初にシークレットを定義します。

# 首先将明文转换成base64编码
echo -n 'root' | base64   # 结果是cm9vdA==
echo -n '123456' | base64 # 结果是MTIzNDU2

次の Secret.yaml ステートメントを使用してシークレットを作成します。作成したばかりのシークレットは、kubectl get Secret を使用して表示できます。

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
data:
  username: cm9vdA==
  password: MTIzNDU2

6.3.1 ボリュームのマウント方法

申告書類は以下の通りです。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec: 
  replicas: 1
  selector: 
    matchLabels:
      app: web             
  strategy: {
    
    }
  template:                
    metadata:
      labels:
        app: web
    spec:                  
      containers:
      - image: nginx:1.14
        name: nginx
        # 挂载到容器内
        volumeMounts:
          - name: secret-volume
            mountPath: /etc/secret-volume
      # 卷声明      
      volumes:
      - name: secret-volume
        secret:
          secretName: test-secret
status: {
    
    }

作成後、コンテナに入ります。コンテナに入るコマンドは次のとおりです。これは docker と一致しています。作成するポッドの名前は web-66d9b4684b-dvwtm ではない場合があります。実際の状況に応じて入力します。

kubectl exec -it web-66d9b4684b-dvwtm bash

マウントされたコンテンツを確認してください。

cat /etc/secret-volume/username  # 显示root
cat /etc/secret-volume/password  # 显示123456

6.3.2 環境変数のメソッド

宣言ファイルは次のとおりです。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec: 
  replicas: 1
  selector: 
    matchLabels:
      app: web             
  strategy: {
    
    }
  template:                
    metadata:
      labels:
        app: web
    spec:                  
      containers:
      - image: nginx:1.14
        name: nginx
        # 环境变量声明
        env:
        - name: SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: test-secret
              key: username
status: {
    
    }

実行後、コンテナー内をチェックして、環境変数が期待値を満たしているかどうかを確認します。出力される値は、設定した Secret である root であるはずです。

kubectl exec -it web-848bb777bc-x5mh4 -- /bin/sh -c 'echo $SECRET_USERNAME'

ここで質問があります。Secret は Base64 エンコード (暗号化ではない) なので、なぜ安全なのでしょうか? ここでのセキュリティは K8S によって提供されます。主に前述の点です。

送信セキュリティ (K8S の API サーバーとの通信は HTTPS です)
ストレージセキュリティ (シークレットはコンテナにマウントされるときに tmpfs に保存され、ディスクではなくメモリにのみ存在し、ポッドはシークレットを破棄して消失します)
アクセスセキュリティ (ポッド間のシークレットは分離されており、あるポッドが別のポッドのシークレットにアクセスすることはできません)

6.4 構成マップ

ConfigMap は、暗号化やセキュリティ属性を必要としない Secret とみなすことができ、構成にも関係します。ConfigMap の作成プロセスは次のとおりです。まず、次の内容を含む redis.properties などの構成ファイルを作成します

redis.port=127.0.0.1
redis.port=6379
redis.password=123456

次のコマンドは、redis.properties ファイルから redis-config という名前の ConfigMap を作成します。

kubectl create configmap redis-config --from-file=redis.properties

コマンド kubectl get configmap を使用して、作成した ConfigMap を表示します。もちろん、ConfigMap にはボリュームをマウントし、Pod 呼び出しの環境変数を設定するメソッドもありますが、ここでは説明しません。

6.5 ストレージオーケストレーション

ストレージオーケストレーションにより、ローカルストレージ、GCP や AWS などのパブリッククラウドプロバイダーによって提供されるストレージ、NFS、iSCSI、Gluster、Ceph、Cinder、Flocker などのネットワークストレージシステムなど、選択したストレージシステムの自動マウントが可能になります。

ストレージに関して言えば、K8S の PV と PVC について説明する必要があります。

PV: PersistentVolume、永続ボリューム
PVC: PersistentVolumeClaim、永続ボリューム要求

率直に言うと、PV はストレージ層を抽象化したものです。基盤となるストレージはローカルディスクでも、NFS や Ceph などのネットワークディスクでも構いません。PV があるのに、なぜ PVC が必要なのでしょうか?

PVC は実際には、Pod と PV の前に別の抽象化レイヤーを追加します。この目的は、Pod のストレージ動作を特定のストレージデバイスから切り離すことです。ある日、NFS ネットワークストレージの IP アドレスが変更されると想像してください。PVC がない場合は、次のことが必要です。各 Pod の IP 宣言を変更するのは非常に面倒ですが、PVC でこれらの詳細を保護すれば、PV を変更するだけで済みます。

6.6 サービスの検出と負荷分散

サービスディスカバリとロードバランシングを使用すると、アプリケーションを変更せずに、なじみのないサービスディスカバリメカニズムを使用できるようになります。Kubernetes はコンテナに独自の IP アドレスと DNS 名を与え、それらの間で負荷分散を行うことができます。

これまでのところ、私たちの Pod は水平スケーリング、自動ボックス化、構成管理、およびストレージオーケストレーションを実現できていますが、アクセスは依然として大きな問題です。拡張後、多数の Pod がどの Pod にアクセスすべきでしょうか? トラフィックを異なる Pod に自動的に分散でき (負荷分散)、拡張または縮小時に負荷分散範囲に対して Pod を動的に追加または削除できる場合、これは簡単に言うとサービス検出です。

では、K8S でサービス検出と負荷分散を実現できるものはあるのでしょうか? 答えは「はい」です。これはサービスです (前に述べた中心的な概念を思い出してください)。サービスには 3 つのタイプがあります。

ClusterIp: クラスター内部アクセス (デフォルト)
NodePort: クラスターへの外部アクセス (ClusterIp を含む)
LoadBalancer: 外部アクセスアプリケーション、パブリッククラウドに使用されます。

6.7 自己修復

自己修復により、障害が発生したコンテナの再起動、ノードの停止時のコンテナの置換と再スケジュール、ユーザー定義のヘルスチェックに応答しないコンテナの強制終了、サービスの準備ができるまでコンテナをクライアントに公開しないことが可能になります。

6.7.1 ポッドの再起動メカニズム

ポッドが異常停止すると、ポッドの再起動メカニズムがトリガーされ、再起動戦略に従ってさまざまな動作が表示されます。

再起動戦略は主に以下の 3 種類に分かれます。

常に: コンテナーが終了して終了すると、常にコンテナーを再起動します。デフォルトのポリシー
OnFailure: コンテナが異常終了した場合のみ再起動します (終了ステータスコードが 0 以外)。
Never: コンテナの終了時に終了し、コンテナを再起動しません。

6.7.2 ポッドのヘルスチェック

名前が示すように、ヘルスチェックは Pod が正常かどうかを確認することです。プログラム内でエラーが発生し、外部にサービスを提供できないが、この時点ではメインプログラムはまだ実行されている、この状態は異常である、またはコンテナのメインプロセスが停止している、という状況があったとします。「開始されました、サービスはまだ準備ができていません。」、この状況も異常であり、アプリケーションレベルからのチェックが必要です。K8S では 2 つのチェックメカニズムが定義されています。

livenessProbe: ライブネスチェックチェックが失敗した場合、コンテナは強制終了され、Pod の restartPolicy に従って操作されます。
readinessProbe: readiness check. チェックが失敗すると、Kubernetes はサービスエンドポイントからポッドを削除します。これは、顧客のトラフィックが、readinessProbe チェックに失敗したポッドにヒットしないことを意味します。

具体的な検査方法は3種類に対応

http Get: HTTP リクエストを送信し、成功として 200 ～ 400 の範囲のステータスコードを返します。
exec: シェルコマンドを実行し、成功の場合はステータスコード 0 を返します。
tcpSocket: TCP ソケットの確立が正常に開始されました

6.8 自動ロールアウトとロールバック

Kubernetes は、アプリケーションの健全性を監視しながら、すべてのインスタンスが同時に終了しないようにしながら、アプリケーションまたはその構成への変更をステージングします。何か問題が発生した場合、Kubernetes は変更をロールバックします。成長を続ける展開オプションのエコシステムを活用する必要があります。

参考文献

K8Sの原理アーキテクチャと実践実装（基礎編）

K8S の原理アーキテクチャと実践的なチュートリアル