はじめに
2022/1/9に投稿した、【OKE超入門】OKE クラスタ クイック作成で Nginxを15分で構築するでNginxを構築したものの、手順が少なすぎて何が作成されたのかいまいちわからない、という方向けに、クイック作成で作成されるリソースをまとめました。Nginx Pod、LoadBalancerタイプのServiceもデプロイしましたので、それもあわせてご説明します。
何作ったんだっけ？
作成手順は下記の通りでした。
1. Cloud Shell の起動
2. Kubernetes クラスタの作成
3. Cloud Shell から Kubernetesクラスタへ接続
4. kubectl を使用したサンプルの Nginx アプリのデプロイ
この記事では、2. Kubernetes クラスタの作成 及び、4. kubectl を使用したサンプルの Nginx アプリのデプロイ の手順を対象にご説明いたします。
全体の構成イメージは下記の通りでした。
1. Kubernetes クラスタの作成 で作られたもの
作成されたリソースを図で表すと下記のようになります。
1-1. Container Engine For Kubernetes (コントロールプレーン)
細かいリソースを見ていく前に、本構成イメージ上でうまく表現されず、抽象化されているアイコンである Container Engine For Kubernetesについて見ていきましょう。
大前提として、kubernetesクラスタは、２つのリソースグループで構成されています。クラスタを管理するコントロールプレーンと、コンポーネント及びワークロードを実行するワーカーノードです。本構成イメージでは、前者のコントロールプレーンとして、Container Engine For Kubernetesのアイコンを表現しています。
「OKE 構成図」でググると、このアイコンがワーカーノードが配置されているVCNの中にいたりしますが、構成イメージを相手方に理解して頂く上で、kubernetesの技術要素とOCIリソースを両立させて描くのに難しいところがあります。そのような構成イメージに出会ったら、一旦は、Container Engine For Kubernetesがコントロールプレーンとして、ワーカーノードにあたるリソースを管理、制御しているんだなーとご理解いただければと思います。
今回は、リソースをご説明するにあたり、このコントロールプレーンと各リソースの通信について語りたかったため、VCNの外にアイコンを表現しています。
コントロールプレーンに属するコンポーネントは下記の通りです。
1. kube-apiserver：kubectl(kubernetesのCLI)等からリクエストされたAPI操作をサポートする
2. kube-controller-manager：様々なKubernetesコンポーネントを管理する
3. kube-sheduler：クラスタ内のジョブを実行する場所を制御する
4. etcd：クラスタの構成データを保存する
5. cloud-controller-manager：type: LoadBalancerのKubernetesサービスが作成されたときにロード・バランサを作成する
５のcloud-controller-managerは、Podをインターネットに公開するため、下記のコマンドを実行した際に活躍してくれたやつです。
kubectl expose deployment nginx-deployment --port=80 --type=LoadBalancer
コントロールプレーンは、利用者（Customer）テナンシーではなく、OCIテナンシーのComputeで稼働しており、Oracleによって完全に管理されています。
こいつのおかげで、OCIリソースであるComputeやBlockStorageをkubernetesネイティブのコンポーネントとして扱ってくれます。
また、先日のクイック作成では、Cloud Shellからこいつのコンポーネントを呼び出して、ワーカーノードにPodやServiceを作っていったことになります。
1-2. Container Engine For Kubernetes (ワーカーノード)
ワーカーノードとは、kubernetesコンポーネント及びワークロードを実行する仮想マシンを指します。
つまり、kubernetesにおけるワーカーノード＝Computeと考えていただいて結構です。
今回作成した構成ではあまりメリットを享受できておりませんが、冗長化のために、構成が全て同じクラスタ内のワーカーノードのセットは、ノードプールにグループ化されて配置されます。（※クラスタには、少なくとも一つのノードプールが必要です。）
クラスタ作成時に、ワーカーノードに属するコンポーネントは下記の通りです。
1. kubelet：クラスタ・コントロール・プレーンと通信する
2. kube-proxy：ネットワーク・ルールを維持する
この上に、PodやServiceをデプロイし、アプリケーションの実行環境として使っていくことになります。
1-3. ブロックストレージ（ブートボリューム）
ワーカーノードのストレージとして、デフォルトでブートボリュームが作成されます。
デフォルト・イメージでは、47GBという値になっています。
「カスタム・ブート・ボリューム・サイズの指定」から、サイズを指定して作成することもできます。
因みに、指定できる最小および最大サイズはそれぞれ50GBおよび32TBです。
ここにPodのデータを持つこともできますが、データを永続化するためにkubernetesのストレージコンポーネントであるPersistent Volume Claimを使用することが一般的です。OCIでは、Persistent Volume Claimとして、ブロックボリューム、FSS（ファイルストレージサービス）を指定することができます。この辺りはまた次の機会に。
1-4. ネットワーク
クイック作成では、ワーカーノードが属する仮想ネットワーク空間として、VCNとそのサブリソースが作成されます。
本ネットワークリソースが、コントロールプレーン、オンプレ等の外部通信を実現しています。
クイック作成で作られるリソースは下記の通りです。
◆仮想クラウド・ネットワーク
- VCN
- インターネット・ゲートウェイ(IG)
- DHCPオプション
◆サブネット
- Kubernetes APIエンドポイントのパブリック・サブネット：kubectl等で実行されたコマンドを基に、コントロールプレーンと通信する
- ワーカー・ノードのパブリック・サブネット：ワーカーノード用のサブネット。
- ロード・バランサのパブリック・サブネット：LoadBalancer用のサブネット。Podへの外部通信を制御する
◆ルート表
- Kubernetes APIエンドポイントのパブリック・サブネットのルート表
- ワーカー・ノードのパブリック・サブネットのルート表
- ロード・バランサのパブリック・サブネットのルート表
◆セキュリティ・リスト
- パブリックKubernetes APIエンドポイント・サブネットのセキュリティ・リスト・ルール
- パブリック・ワーカー・ノード・サブネットのセキュリティ・リスト・ルール
- パブリック・ロード・バランサ・サブネットのセキュリティ・リスト・ルール
これに加え、クラスタ作成時にワーカーノードの配置先をプライベートサブネットにした場合には、サービスゲートウェイとNATゲートウェイが構築されます。
一般的に、LoadBalancer、Compute、DBCSで3層アーキテクチャを組むときにVCNで設定するリソースが作成されるわけなのですが、特筆すべきは３つサブネットが作成され、各サブネットがそれぞれ役割を持っていることです。
中でも、Kubernetes APIエンドポイントのパブリック・サブネットには、コントロールプレーンと通信するためのVNICが用意されており、ユーザがコマンドを実行した場合、このエンドポイントからコントロールプレーンのkubernetesコンポーネントを呼び出し、結果をワーカーノードに反映する仕組みになっています。
kOCIの公式リファレンスで示されていた下図がルート表、セキュリティリスト含め、通信の流れを最もわかりやすく示していました。
【参照】ネットワーク・リソース構成例
Kubernetes APIエンドポイント、ワーカー・ノードのサブネットはプライベートにすることができるのですが、その際の通信についても説明されています。
以上が、OKEクラスタクイック作成から、数クリックで作られるリソースの一覧となります。
では次に、 kubectl を使用したサンプルの Nginx アプリのデプロイ で作成されたリソースについて見てみましょう。
2. Nginx アプリのデプロイ で作られたもの
Nginx アプリのデプロイでは、kubernetesコンポーネントで言うと、下記２つのリソースを作成しました。
- NginxのPod × ２
- type=LoadBalancerのService × １
ワーカーノードの最終的な構成イメージは下記の通りです。
OCI上で、type=LoadBalancerのServiceコンポーネントは、OCI Load Balancer が作成されることと同義です。
つまり、本記事の冒頭で示した図の通り、クライアントからのhttp通信を受け、Podに通信を振り分けてくれるLoad BalancerがLoad Balancerサブネットに作成されたことになります。
まとめ
ほんの数クリック、数コマンドでこれだけのリソースを作成しました。
VPN, Compute, Storage, LBなど、IaaSにあたるサービスをご理解されている方は、OKEへのハードルも少し下がったのではないでしょうか。
今後も、OKE関連の記事を投稿できたらと考えています。