【OKE超入門】OKEクラスタ 作成で作られるリソース　まとめ

#はじめに

2022/1/9に投稿した、[【OKE超入門】OKE クラスタ クイック作成で Nginxを15分で構築する](https://qiita.com/yama6/items/752cf6a4ac2408b5ed35 "【OKE超入門】OKE クラスタ クイック作成で Nginxを15分で構築する")でNginxを構築したものの、手順が少なすぎて何が作成されたのかいまいちわからない、という方向けに、クイック作成で作成されるリソースをまとめました。Nginx Pod、LoadBalancerタイプのServiceもデプロイしましたので、それもあわせてご説明します。

#何作ったんだっけ？

作成手順は下記の通りでした。

**1. Cloud Shell の起動**
**2. Kubernetes クラスタの作成**
**3. Cloud Shell から Kubernetesクラスタへ接続**
**4. kubectl を使用したサンプルの Nginx アプリのデプロイ**

この記事では、[2. Kubernetes クラスタの作成](https://qiita.com/yama6/items/752cf6a4ac2408b5ed35#2-kubernetes-%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E3%81%AE%E4%BD%9C%E6%88%90 "2. Kubernetes クラスタの作成") 及び、[4. kubectl を使用したサンプルの Nginx アプリのデプロイ](https://qiita.com/yama6/items/752cf6a4ac2408b5ed35#4-kubectl-%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AE-nginx-%E3%82%A2%E3%83%97%E3%83%AA%E3%81%AE%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4 "4. kubectl を使用したサンプルの Nginx アプリのデプロイ") の手順を対象にご説明いたします。

全体の構成イメージは下記の通りでした。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2325706/6a29c0ca-aab7-9660-ffdc-1794ee4cb2a7.png)

#1. Kubernetes クラスタの作成 で作られたもの

作成されたリソースを図で表すと下記のようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2325706/6446eda5-c965-d1eb-a796-b1fb7800fa36.png)

#1-1. Container Engine For Kubernetes (コントロールプレーン)

細かいリソースを見ていく前に、本構成イメージ上でうまく表現されず、抽象化されているアイコンである Container Engine For Kubernetesについて見ていきましょう。
大前提として、kubernetesクラスタは、２つのリソースグループで構成されています。クラスタを管理する**コントロールプレーン**と、コンポーネント及びワークロードを実行する**ワーカーノード**です。本構成イメージでは、前者の**コントロールプレーン**として、Container Engine For Kubernetesのアイコンを表現しています。

:::note warn
「OKE　構成図」でググると、このアイコンがワーカーノードが配置されているVCNの中にいたりしますが、構成イメージを相手方に理解して頂く上で、kubernetesの技術要素とOCIリソースを両立させて描くのに難しいところがあります。そのような構成イメージに出会ったら、一旦は、Container Engine For Kubernetesがコントロールプレーンとして、ワーカーノードにあたるリソースを管理、制御しているんだなーとご理解いただければと思います。
今回は、リソースをご説明するにあたり、このコントロールプレーンと各リソースの通信について語りたかったため、VCNの外にアイコンを表現しています。
:::

コントロールプレーンに属するコンポーネントは下記の通りです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2325706/9817bdbe-9ede-56ff-8fc2-1fdbc29a694c.png)
**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と考えていただいて結構です。**
今回作成した構成ではあまりメリットを享受できておりませんが、冗長化のために、構成が全て同じクラスタ内のワーカーノードのセットは、ノードプールにグループ化されて配置されます。（※クラスタには、少なくとも一つのノードプールが必要です。）

クラスタ作成時に、ワーカーノードに属するコンポーネントは下記の通りです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2325706/08af791b-1158-5a61-64ae-32874e5cf1a3.png)
**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とそのサブリソースが作成されます。
本ネットワークリソースが、コントロールプレーン、オンプレ等の外部通信を実現しています。
クイック作成で作られるリソースは下記の通りです。

**◆仮想クラウド・ネットワーク**
 1. VCN
 2. インターネット・ゲートウェイ(IG)
13. DHCPオプション

**◆サブネット**
1. Kubernetes APIエンドポイントのパブリック・サブネット：kubectl等で実行されたコマンドを基に、コントロールプレーンと通信する
2. ワーカー・ノードのパブリック・サブネット：ワーカーノード用のサブネット。
3. ロード・バランサのパブリック・サブネット：LoadBalancer用のサブネット。Podへの外部通信を制御する

**◆ルート表**
1. Kubernetes APIエンドポイントのパブリック・サブネットのルート表
2. ワーカー・ノードのパブリック・サブネットのルート表
3. ロード・バランサのパブリック・サブネットのルート表

**◆セキュリティ・リスト**
1. パブリックKubernetes APIエンドポイント・サブネットのセキュリティ・リスト・ルール
2. パブリック・ワーカー・ノード・サブネットのセキュリティ・リスト・ルール
3. パブリック・ロード・バランサ・サブネットのセキュリティ・リスト・ルール

これに加え、クラスタ作成時にワーカーノードの配置先をプライベートサブネットにした場合には、サービスゲートウェイとNATゲートウェイが構築されます。
一般的に、LoadBalancer、Compute、DBCSで3層アーキテクチャを組むときにVCNで設定するリソースが作成されるわけなのですが、特筆すべきは３つサブネットが作成され、各サブネットがそれぞれ役割を持っていることです。
中でも、Kubernetes APIエンドポイントのパブリック・サブネットには、コントロールプレーンと通信するためのVNICが用意されており、**ユーザがコマンドを実行した場合、このエンドポイントからコントロールプレーンのkubernetesコンポーネントを呼び出し、結果をワーカーノードに反映する仕組みになっています。**

kOCIの公式リファレンスで示されていた下図がルート表、セキュリティリスト含め、通信の流れを最もわかりやすく示していました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2325706/4f9447d6-f0cd-3236-495a-92eeb17dd62c.png)
【参照】[ネットワーク・リソース構成例](https://docs.oracle.com/ja-jp/iaas/Content/ContEng/Concepts/contengnetworkconfigexample.htm#example-publick8sapi-publicworkers-publiclb "ネットワーク・リソース構成例")
Kubernetes APIエンドポイント、ワーカー・ノードのサブネットはプライベートにすることができるのですが、その際の通信についても説明されています。

以上が、OKEクラスタクイック作成から、数クリックで作られるリソースの一覧となります。
では次に、 kubectl を使用したサンプルの Nginx アプリのデプロイ で作成されたリソースについて見てみましょう。

#2. Nginx アプリのデプロイ で作られたもの

Nginx アプリのデプロイでは、kubernetesコンポーネントで言うと、下記２つのリソースを作成しました。
1. NginxのPod × ２
2. type=LoadBalancerのService × １

ワーカーノードの最終的な構成イメージは下記の通りです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2325706/073e51ae-7b11-0ddc-fb15-ae0316634e51.png)

OCI上で、type=LoadBalancerのServiceコンポーネントは、OCI Load Balancer が作成されることと同義です。
つまり、本記事の冒頭で示した図の通り、クライアントからのhttp通信を受け、Podに通信を振り分けてくれるLoad BalancerがLoad Balancerサブネットに作成されたことになります。

#まとめ

ほんの数クリック、数コマンドでこれだけのリソースを作成しました。
VPN, Compute, Storage, LBなど、IaaSにあたるサービスをご理解されている方は、OKEへのハードルも少し下がったのではないでしょうか。
今後も、OKE関連の記事を投稿できたらと考えています。