0.はじめに
以前からコンテナオーケストレーションツールに興味はあったものの、触る機会が無かったのでこちらの書籍を元に学習してみたので、kubernetesの仕組みを理解するための要点だけを図にまとめてみました。
ハンズオンで分かりやすく学べる Google Cloud実践活用術 データ分析・システム基盤編 Google監修
本記事ではネットワーク、Docker等の前提知識は割愛します。
画像については、引用はせずdraw.ioで描いてるので、見づらい部分があればコメントいただければ幸いです。
1.kubernetesの特徴
kubernetesはコンテナオーケストレーションツールであり、主に以下のような特徴があります。
- コンテナを動かすホストである
- コンテナをどこに配置するか等のスケジューリングが行える
- コンテナ間のサービスディスカバリー（名前解決と通信）
- コンテナ間のロードバランシング
- オートスケーリング（コンテナ数や１台あたりの性能増減）
- ローリングアップデート（少しずつ新しいコンテナへ入れ替えていく）
2.kubernetesの内部アーキテクチャ
次項のネットワーキング、デプロイフローを見る前に、まずはkubernetesの内部を見ていきます。
ControlPlanes
上図ControlPlanes内の機能は以下の通りです。
Control plane
後述のNodeを制御するための基盤であり、kube-apiserver、kube-controller-manager、kube-scheduler、etcdの４つのコンポーネントで構成されています。
kubectl
kube-apiserverにリクエストを送信するためのCLIツール。
Kubernetesクラスターは、このCLIツールを使うか、マニフェストと呼ばれるyaml形式のファイルによって設定できます。
kube-apiserver
Kubernetesの各APIを提供するコンポーネント。
kubectlからのAPIリクエストや他のコンポーネントからもアクセスされます。
KubernetesのAPIリソースは以下のようなものがあります。
- Workload Resources
- Service Resources
- Config and Storage Resources
- Authentication Resources
- Authorization Resources
- Policy Resources
- Extend Resources
- Cluster Resources
- Common Definitions
- Common Parameters
reference: https://kubernetes.io/docs/reference/kubernetes-api/
kube-controller-manager
DeploymentコントローラーやReplicaSetコントローラーといった、APIリソースごとに実際の処理を行うコントローラーを１つのバイナリファイルにまとめたもの。
kube-scheduler
新たに作られたPodのうち、Nodeが割り当てられてないものに対し、どのNodeを割り当てるかをkube-apiserverにリクエストしてスケジューリングする。
etcd
キーバリューストア（KVS）となっていて、Kubernetesクラスターの全ての情報を保存している。
Nodes
上図Nodes内の機能は以下の通りです。
Node
Podを実行できる環境、ワーカーマシン。
クラスター内に複数配置でき、NodeごとにNICが割り当てられるため、Node間の通信も可能です。
kube-proxy
各Node上で動作するネットワークプロキシー。
別Nodeもしくは外部からClusterIP・NodePort宛にリクエストがあった場合、各Podに転送します。
kubelet
Dockerやcontainerdといったコンテナランタイムと連携して、Podの起動や停止を行う。
Pod
１つ以上のコンテナで構成されるKubernetesの基本となるリソース。
1つのPod内に複数コンテナを設置する場合、ネットワークインターフェースを共有して1つのIPアドレスを持ちます。
アドオン
Node上で動作する代表的なアドオンは次のようなものがあります。
- kube-dns： ServiceリソースのDNS名〜PodのIPアドレスの名前解決をするコンポーネント
- Reconciliation loop： マニフェストの定義と現在の状態を比較して、差分を是正するコンポーネント
3.kubernetesのネットワーキングを理解する
ここでは４つの図からkubernetesのネットワークを見ていきます。
但し、プロキシモードの設定によって図の構成は変わってくるのでご注意ください。
https://kubernetes.io/ja/docs/concepts/services-networking/_print/#virtual-ips-and-service-proxies
こちらのサイトも分かりやすかったので参考になると思います。
https://www.netone.co.jp/knowledge-center/netone-blog/20210715-01/
Serviceリソース
クラスター内部での通信（ClusterIP）
kubernetesはServiceリソースに対してIPアドレスを割り当てており、これをClusterIPと呼びます。
ClusterIPを使うことで、クラスター内部での通信を実現できます。例えばPod間の通信です。
クラスター外部からの通信（NodePort）
Serviceの公開タイプにNodePortを設定した場合の説明です。
https://kubernetes.io/ja/docs/concepts/services-networking/service/#nodeport
NodePortはクラスター外部からのアクセス向けに各NodeのIPアドレスを提供します。
トラフィックを受信すると、kube-proxyの設定に従ってPodへの転送を行います。
また、kube-proxyはパケットフィルタリング機能もあるようです。
https://kubernetes.io/ja/docs/concepts/overview/components/#kube-proxy
LoadBalancerによるL4レベルのロードバランシング
Serviceの公開タイプにLoadBalancerを設定した場合の説明です。
https://kubernetes.io/ja/docs/concepts/services-networking/service/#loadbalancer
トラフィックを受信したロードバランサーは、各NodeのIPに負荷分散しながら転送します。
Ingressリソース
IngressによるL7レベルのロードバランシング
Ingressを使うことで、パス単位で振り分けるService・Podを設定できます。
使うにはIngressコントローラを用意します。
https://kubernetes.io/docs/concepts/services-networking/ingress/
上図の例では、
https://example.com/video にアクセスすると、kube-proxyの設定に従って紫のPodへ転送します
https://example.com/article にアクセスすると、kube-proxyの設定に従って黄のPodへ転送します
https://example.com/shop にアクセスすると、kube-proxyの設定に従って緑のPodへ転送します
4.kubernetesのデプロイフローを理解する
まずは図に登場するリソースの説明です。
ReplicaSet
Podのレプリカ（複製）を管理するリソースです。（AWSでいうAMIに近いかもしれません）
ReplicaSetはServiceリソースと組み合わせて負荷分散、水平スケーリング（HorizontalPodAutoScaler）するときによく使われます。
ReplicaSetは単体で使うことは少なく、Deploymentに内包される形でよく使われます。
Deployment
DeploymentはReplicaSetとPodを抽象化したものです。
Deploymentを作成すると、対応するReplicaSetとPodが自動的に作成されます。
直接ReplicasetとPodを操作せずにDeploymentを利用するメリットは、
ローリングアップデート（古いReplicaSetのPod数と新しいReplicaSetのPod数を調整しながら少しずつPodを入れ替える）やロールバックが簡単にできる点です。
ここではPod作成を例に図にしてみます。
次に示す順でPodの作成処理が行われます。
- ユーザーがkubectlでDeployment作成をリクエストorマニフェストの更新
- DeploymentControllerがDeploymentの作成を検知し、ReplicaSetを作成
- ReplicaSetControllerがReplicaSetの作成を検知し、Podを作成
- kube-schedulerが新規Podを検出し、Podを実行するNodeを指定
- 指定されたNodeのkubeletが検知し、Pod（コンテナ）を起動
5.GKE（Google Kubernetes Engine）の特徴
KubernetesのマネージドサービスであるGKEは次のような特徴があります。
- 構築するのが難しいとされるControl planeの管理が不要
- OSSであるKubernetesは四半期に一度マイナーバージョンがリリースされるが、これを自動アップデートする機能がある
- 上記に加え、Control planeやNodeのソフトウェアを自動でアップデートする機能がある
- Node pool（同じ構成のNodeのグループ）という仕組みにより、ダウンタイムを最小限に抑えながらKubernetesのアップデートができる
- Node poolのサイズを自動スケールするCluster Autoscaler
- Node auto-repairという、GKEが修復が必要と判断したNodeを検知して、自動的にドレイン（修復が必要なNode上のPodを別の正常なNodeに追い出す）して、Nodeを再作成する機能がある。
6.最後に
次回はRailsアプリケーションをGKEにデプロイするところまでをまとめてみます。
Next→ Comming soon