はじめに
「RKSを知る！」の連載第8回目の記事としまして、RKSにて構築したクラスタ上に展開されているコンポーネントPodやアドオンPodにどんなものが存在するかの調査結果について解説しようと思います。
まずコンポーネントPodやアドオンPodについて、どのようなものを指しているかの解説から、CRI/CNIについてもどのようなものを使用しているか、確認できた範囲まで解説したいと思います。
本連載についてはリンクページを用意していますため、概要や連載記事は下記URLからご確認ください。
RKSを知る！ 概要＆連載リンク集
kubernetesのコンポーネントとは？
kubernetesのクラスタ環境を構成しているコンポーネントは全てPodにて展開されています。
以下のコマンドにてNameSpace : kube-systemを確認してみると、デフォルトの状態で様々なPodが存在するのが確認できると思います。
kubectl get pods -n kube-system -o wide --sort-by="{.spec.nodeName}"以下はvirtualBox上に構築したシングルコントロールプレーンのkubernetesクラスタに対し、上記コマンドを実行した結果となります。
上記のコマンド結果にて注目すべきは、Pod名の後ろにmasterとついているPodです。
これらNode名が後ろに付くPodはstaticPodと呼ばれており、各Node上に直接Pod定義を配置することで、展開可能となるPodとなります。
以下の図はkubernetes公式ドキュメントのに存在するKubernetesコンポーネントの全体像となります。
図中のkubernetes Control Planeに存在する以下4つのコンポーネントと、上記画像のMasterに存在するStaticPodの内容が一致していることが確認できると思います。
これらがKubernetesクラスタのコンポーネントの実体となります
MasterNodeコンポーネント
- kube-apiserver
kubernetesの本体ともいえる、各APIを提供しているコンポーネント - kube-controller-manager
kubernetesオブジェクト処理のコントローラーを管理するコンポーネント - kube-scheduler
各NodeへのPodスケジューリングを管理するコンポーネント - etcd
クラスター情報すべてを管理するKey-Valueストア
WorkerNodeコンポーネント
- kubelet
各WorkerNodeでPod実行を行うコンポーネント。
kubeletのみはPodではなく、インストールする必要があるエージェントです。 - kube-proxy
クラスター内の各Nodeで動作しているネットワークプロキシ
また、StaticPod以外にも様々なPodが確認できると思いますが、これらはKubernetesクラスタをサポートするアドオンとなっています。
kubeadmによるインストールで必ず導入されるアドオンもあれば、クラスタによって導入されるアドオンが異なる場合もあります。
簡単にですが、上記画像で確認できるアドオンについて解説したいと思います。
- CoreDNS
ServiceとPodといったKubernetesサービスのDNSレコードを提供するDNSサーバー - Calico
コンテナ間のネットワーク通信をサポートするCNI
CNIはデフォルトでは導入されず、構築するクラスタによって導入するCNIを選択する必要があります。
上記画像ではCNIの一つであるCalicoを導入しています。
RKSのコンポーネント
では、RKSのコンポーネントはどのようなものが存在するのでしょうか？
先ほどと同じようなコマンドを実行し、内容を確認してみます。
(sort対象はNameに変更しています)
先ほどのシングルコントロールプレーンKubernetesクラスタと異なるPodがいくつも確認できると思います。
見慣れたものもあれば、Ridge特有のPodも確認でき、具体的にどういったPodがどのような機能をもっているか一見して分かりずらいものであると思います。
上記画像について、RKSのクラスタで確認できたPodについて、調査結果を解説したいと思います。
- cloud-controller-manager
クラウドサービスと連携をとるMasterNodeコンポーネント
クラスタとクラウドプロバイダーAPIをリンクさせ、クラスタとクラウドが相互連携を取れるようサポートします。
RKSのcloud-controller-managerはRidgeCloudと連携するよう機能しています。 - csi-ridge-controller(csi-ridge-node)
CSI(Container Storage Interface)を管理するアドオン
Master1機にコントローラーが配置されており、他のNodePodと連携を取り、リソースプール上のストレージリソースを利用するよう連携を行っています - fluent-bit
ログ収集のミドルウェアであるFluentdを、より軽量化しコンテナサービス等で活用できるにしたマイクロサービスアドオン
RKSにて稼働しているコンテナのログはfluent-bitにより収集されます - meta
構築したクラスタのメタ情報を各Nodeに展開するアドオン
daemonsetで展開されており、引数でメタ情報を各Podに連携しています - ridge-auth
RidgeCloudに対する認証情報を管理しているアドオン
DaemonsSetで展開されており、Masterにのみ存在しています
RKSクラスタのCRI
RKSのクラスタのCRIですが、こちらはRKSの特性上、確認することが出来ませんでした…
CRI(Container Runtime Interface)はコンテナを実際に稼働させる機能であり、Kubeletに紐づいて設定されています。
kubeletの設定情報ですが、こちらは各Nodeに直接アクセスし、設定ファイルからのみ確認でき、kubectlからでは確認することは出来ません。
連載第3回で解説しましたが、RKSで構築したクラスタ上のNodeへ直接アクセスすることは出来ず、kubectlを用いたクラスタ操作のみサポートしています。
そのため、Kubeletの設定情報に記載されているCRI情報を確認することが出来ず、残念ながら現状どのようなCRIを使用しているか確認することが出来ませんでした。
RKSクラスタのCNI
kube-systemに展開されているCNIを確認したところ、Weave-Netを使用していることが確認できました。
WeaveWork社が提供しているCNIで、他のCNIのようにクラスタ構築時に引数でpod-network-cidrを指定する必要が無い等、利便性に優れており、最近人気のCNIとなっています。
マネージドKubernetesサービス全般に言えることなのですが、クラウドサービスにて構築されるクラスタのCNIはユーザ側が指定することは出来ず、自動構築時にクラウドベンダが指定したCNIを導入されることになります。
あとがき
今回は連載第8回目としまして、RKSクラスタに展開されているコンポーネントやアドオン、CRIやCNIの調査結果を紹介しました！
基本的なコンポーネントはオンプレ環境で作成したKubernetesクラスタと似通っていますが、メタ情報や認証情報などをPodで展開したり、ログ収集のPodをデフォルトで導入していたり等、他のマネージドKubernetesサービスでは見られない特徴なども確認することが出来ました！
CRIについては残念ながら確認することは出来ませんでしたが、今後Ridgeとやり取りを続けていく中で確認するタイミングがありましたら、確認してみたいと思います！
ここまでお読みいただき、ありがとうございました！
