初心者からのKubernetes入門と基本機能の動作例
1.コンテナとオーケストレーションツール
- コンテナはそれ単体では単なるプロセスであり、実際にコンテナとしてアプリケーションを動かすには複数のコンテナを協調させて動かす必要がある（WebサーバーコンテナやDBサーバーコンテナなど）。
- 特に大規模や企業の商用サーバー用途では以下の考慮点が必要。
– 分散環境での複数のコンテナのデプロイ・管理
– 資源配置の最適化（各サーバーのCPUやメモリ等のリソース状況を考慮してどのサーバーにコンテナをデプロイするかなど）
– 負荷分散、冗⻑化、負荷増加時のスケール
– コンテナの監視
– アップデート（コンテナのバージョンアップなど） - それらを引き受け、コンテナ化されたアプリケーションのデプロイや管理を自動化するのがオーケストレーションツール。
2.Kubernetesとは
- オーケストレーションツールのデファクトスタンダード。
- 元はGoogleが独自に開発して車内で運用していたコンテナ管理システム。Googleは毎週20億個のコンテナを生成(https://goo.gl/w7oBxe)
- 2014年にOSSとして公開、2015年にCNCFに寄贈。
- CNCFとは
-CNCF:Cloud Native Computing Foundation(https://www.cncf.io/)
–Linux Foundationを組織の母体とする非営利組織。2015年7月21日設立。
–各クラウド事業者もCNCFに加入（Amazon Web Services, Microsoft, IBM etc)。
–最先端のクラウドネイティブなアプリケーションやサービスの開発を促進することを目的とする団体。
–クラウドネイティブとは、OSSのスタックを使い、コンテナ化を実現し、マクロサービスのアプリケーションを動かせるようにすること。
–KubernetesはCNCF傘下のプロジェクトであり、CNCFにおいて、Kubernetesの仕様の今後の開発について議論され、CNCFメンバー36社が、統一した規格と仕様を決めることに合意している。(https://goo.gl/e24imz)
-大手企業での採用も進んでいる：New York Time, Goldman Sachs, Person, PHILIPS, Yahoo! Japan, CONCUR, BOX, Pokemon GO
-上記のメンバー間での合意や大手企業での採用状況がKubernetesがデファクトスタンダードと言われる所以の一つとなっている。
3.Kubernetesのアーキテクチャ
3-1.Kubernetesクラスタ
- 多数のマシンで構成されるスケールアウト型のアーキテクチャを前提としており、各ノード（物理サーバーやVMの上で動く仮想サーバーなど）の集合を「クラスタ」という単位でグループ化する。
- ノードは以下の種別に分類される。
-Master node: クラスタ全体の管理を担う
-Worker node: Masterから指示を受けてアプリケーションのコンテナを実行
Kubernetesのアーキテクチャ
3-2.Master nodeとWorker nodeの構成要素
- 以下がMaster nodeとWorker node上の主要な構成要素。
- Worker node上のPodに関しては以降で別途説明。
Master nodeとWorker nodeの構成要素
Master nodeとWorker nodeの構成要素（コンポーネント）一覧
3-3.Pod
- Kubernetesでは、1個以上のコンテナを包含する「Pod」という単位でデプロイを行います。
- Podには以下の特徴があります。
–１つ以上のコンテナを包含する
–Pod内の全コンテナが同一のNodeにデプロイされることが保証される
–仮想IPを共有する
–localhostでコンテナ間が通信できる
–ボリュームを共有できる
–スケールアウトはPod単位で行われる（個々のコンテナ単位ではない）
- どういう場合に複数コンテナを1つのPodに集約するのか
–コンテナ同士が密接に連携する
–同時にスケールさせたい
-例）
・Webサーバーコンテナとそれを監視するコンテナなど。
・スケールのさせ方が違うWebサーバー（スケールウト）とDBサーバー（スケールアップ）を集約させるのはアンチパターン。
4.クラスタへのデプロイの流れ
- Kubernetesクラスタへのアプリケーションデプロイ手順は以下のようになります。
- Masterに対してデプロイすべきコンテナのイメージや個数などの情報を指示する（YAML, JSON）
- Masterは指示された構成情報をetcdに永続化する
- Masterは情報に基づいて、コンテナをデプロイすべきNodeを決定する
- MasterはNodeに対してコンテナの実行を指示する
- Nodeは必要に応じて指定されたコンテナイメージをpullしたうえで実行する
- デプロイ指示（YAML）例
kubectl apply -f healthcheck.yml
5.Kubernetsの主要機能
5-1-1.ReplicaSet
- 冗長性や負荷分散を考慮し同じPodを複数デプロイしたい場合、1つ1つPodをデプロイすることも可能だが、ReplicaSetを使用することで複数のPodをまとめてデプロイすることが可能。
- ReplicaSetは指定されたイメージ・個数のPodを自動で作成してくれる仕組み。
- ReplicaSetは条件に従ってPodを検索し、稼働しているPodの数がreplicasと一致しているかどうかをチェック。
- repilcasよりも少ない場合は新規にPod追加し、多いときは余剰分のPodを停止する。
- ReplicaSetを指定
- 作成したPod数を指定
- 作成するコンテナイメージを指定
5-1-2.ReplicaSetによるオートヒーリング時の動作例
- YAMLからReplicaSetを作成（spec.replicas:2で作成）
- ReplicaSetのステータス
- ReplicaSet内のPodのステータス
- Podを1つ削除
- Podが1つ削除され、新たに別のPodが起動
※オートヒーリングによって起動されるPodは、障害などによって停止したPodの状態を引き継ぐわけではない。
※オートヒーリングによる回復はあくまで「指定されたコンテナイメージを利用してPodを再度起動する」機能。
5-2.Liveness ProbeによるPodのヘルスチェック
- オートヒーリングではPodが稼働しているかどうかは、単純にPod内のコンテナのプロセスが稼働しているかどうかで判断。
- Liveness ProbeではPodの定義に対して次のヘルスチェックを追加ですることで、サービスレベルのPodの監視が可能となる。
–HTTP GET : 指定されたURLにHTTP GETを発行し、レスポンスが正常であることを確認
–TCP Socket : 指定されたポートに接続し、TCP接続が確立できることを確認
–Exec : 指定されたコマンドをコンテナ内で実行し、ステータスコードが0であることを確認
5-3-1.Service
- Podは実際にデプロイされるまでIPアドレスはわからないし、オートヒーリング等で作り直された際はIPアドレスも変化するため、固定のアクセス先を決めることができない。
- Serviceは複数のPodで構成されるサービスを代表し、外部からのアクセスを可能とする。
- Serviceを作成することで、IPアドレスを意識することなく各Podにアクセス可能となる。
- Serviceの要素は次の通り。
–ClusterIP: スタティックなIPアドレス（クラスタ内IP）
–port : Pod側ポート番号
–targetPort : 外部公開ポート
–selector : サービスを構成するPodを特定するラベル
5-3-2.Serviceによる外部からのアクセス例
- worker nodeのIP
- Podと外部公開ポート
5-4.Readiness ProbeによるPodのヘルスチェック
- Readiness Probeは、Podの定義に対して以下のヘルスチェックを追加することで、Podの初期化処理が完了しサービスに応答できる状態になるまではService経由でのPodの公開を抑制できる。
–HTTP GET : 指定されたURLにHTTP GETを発行し、レスポンスが正常であることを確認
–TCP Socket : 指定されたポートに接続し、TCP接続が確立できることを確認
–Exec : 指定されたコマンドをコンテナ内で実行し、ステータスコードが0であることを確認
5-5-1.Deployment
- Deploymentはアプリケーションの新しいバージョンのリリースを管理する仕組みで、アプリケーションのアップデートやロールバックを宣言的に行うことを可能とする。
- Deploymentはその配下にReplicaSetをもち、ReplicaSet単位のバージョンを管理する。
- アップデートやロールバックのさせ方（strategy）は以下の2種類を設定可能。
＜RollingUpdate(デフォルト)＞
- Podを順次停止しアップデートしていく。
- Recreateよりも動作は遅いが、ユーザートラフィックを受けながらサービスのバージョンアップが可能。
- maxSurge:
- アップデート実行中に指定されたscaleよりも余分に起動して良いPod数を絶対値もしくは%で指定。
- maxUnavailable :
- アップデート実行中に指定されたscaleを割り込んでも良いPod数を絶対値もしくは%で指定。
＜Recreate＞
- アップデート前に旧バージョンのPodを全て停止してから新バージョンのPodを起動する。
- バージョン混在は回避できるが、ユーザーからみるとサービス停止が発生する。
- Deploymentを指定（ReplicaSetは指定不要。自動で作成される）
- Deploymentの種類を指定（ROllingUpdateがデフォルト）
- コンテナのテンプレートが変更になるとアップデートされる
5-5-2.Deploymentによるローリングアップデート時の動作例
- YAMLからDeploymentを作成
- Deploymentのステータス
- ReplicaSetのステータス確認
- Deployment定義の対象コンテナイメージを変更
- ロールアウトのステータス確認
- Deploymentのステータス確認
- ReplicaSetのステータス確認
