Kubernetesアーキテクチャ概要
Kubernetesの構成要素
Kubernetesクラスタは、以下の8つのコンポーネントから構成されています。
- etcd
- kube-apiserver
- kube-sheduler
- kube-controller-manager
- kubelet
- kube-proxy
- CNI Plugin
- kube-dns
オプションとして、cloud-controller-managerを追加する場合もあります。
ユーザは主に、kube-apiserverを介して、クラスタ操作を行います。
etcd
etcdは、分散キーバリューストア(KVS)です。
etcdには、Kubernetesクラスタの構成情報がすべて保存されるため、冗長化構成にすることが強く推奨されます。
分散合意アルゴリズムにはRaftが採用されており、3台または5台といった奇数台で冗長化構成を組みます。
kube-apiserver
kube-apiserverは、その名の通りKubernetes APIサーバです。
kubectlコマンドは、kube-apiserverと通信を行なっています。
Kubernetesクラスタは、kube-apiserverを中心として、各コンポーネントが協調的に動作します。
kube-scheduler
kube-schedulerは、起動するノードが未割り当てのPodを検知し、各ノードのステータス、Node Affinity、Inter-Pod Affinityなどの条件に合致するかの判定を行なった上で、Podを起動するノードを決定します。
Pod起動の流れ
- kubectlからPodリソースを登録
- kube-apiserverはPod情報をetcdに書き込む
- kube-schedulerはPodを起動するノードを決定し、etcdにあるPod情報のうち、spec.nodeNameを更新
- kubeletはspec.nodeNameを参照し、自身のノードでまだ起動していないPodがあれば起動
kube-controller-manager
kube-controller-managerは、様々なコントローラを実行します。
例えば、Deployment ControllerやReplicaSet Controllerは、DeploymentやReplicaSetのステータスを監視しながら、ReplicaSetやPodの作成・更新をトリガーします。実際の作成・更新のスケジューリングは、kube-schedulerの役割です。
kube-controller-managerも冗長化構成が可能です。
kubelet
kubeletは、各Kubernetesノード上でコンテナランタイムと連携して、コンテナの起動・停止を行います。
kubeletが連携可能な(高レイヤ)コンテナランタイム
- Docker
- containerd
- CRI-O
- Frakti
kubeletはContainer Runtime Interface(CRI)を用いて、高レイヤコンテナランタイムとやり取りを行います。
また、高レイヤコンテナランタイムはOpen Container Initiative(OCI)を用いて、低レイヤコンテナランタイムとやり取りを行います。
低レイヤコンテナランタイムには、runc/runv/runsc(gVisor)があります。
kube-proxy
kube-proxyも、各Kubernetesノード上で動作し、ServiceリソースのClusterIPやNodePort宛の通信がPodに転送されるようにします。
転送方式として、次の3つのモードが用意されています。
- userspaceモード
- iptablesモード
- ipvsモード
IPVSはIP Virtual Serverの略で、この方式はカーネル空間での処理による高パフォーマンス、ロードバランシング機能搭載による高スケーラビリティを実現しています。
現時点では、iptablesモードが最も利用されています。
CNI Plugin
Container Network Interface(CNI)Pluginは、ノード間のオーバーレイネットワークを構築し、異なるノードで動作するPod間の通信を可能にします。
Kubernetesが対応しているCNI Plugin
- Flannel
- Open vSwitch
- Project Calico
- Cilium
- Contiv
- Romana
- Weave Net
Flannelには、NetworkPolicyリソースが利用できないという制約があります。
kube-dns
kube-dnsは、Kubernetesクラスタ内部の名前解決やサービスディスカバリに使用されるDNSサーバです。
kube-dnsは、内部でCoreDNSを利用しています。
cloud-controller-manager
cloud-controller-managerは、Kubernetesクラスタをクラウドと連携する際に使用します。
例えば、LoadBalancer Serviceを作成した際にクラウドのロードバランサーと連携したり、Nodeが作成された際にそのNodeにリージョンやゾーン情報のラベルを付与したりします。
その他コンポーネントとクラスタ正常性テスト
オプションになりますが、Ingress ControllerはIngressリソースが作成された際に、L7ロードバランサを作成するコンポーネントであり、有用です。
また、Heptio社開発のSunobuoyというツールを使用すると、クラスタ全体の正常性テストができます。
カスタムリソース
Kubernetesは、独自のリソースを定義して追加できるようになっています。
独自リソースの定義には、以下のようなCustom Resource Definition(CRD)のマニフェストを使います。
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: newresources.stable.example.com
spec:
group: stable.example.com
scope: Namespaced
names:
plural: newresources
singular: newresource
kind: NewResource
shortNames:
- nrs
[後略]
上記のCRDを登録すると、下記のNewResource
リソースが利用可能になります。
apiVersion: stable.example.com/v1
kind: NewResource
metadata:
name: example-newresource
spec:
[後略]
NewResource
リソース作成後には、kubectl get newresources
でNewResource
リソース一覧を表示できます。
独自リソースが作成されたときに行う実際の処理は、Operatorとして実装する必要があります。
Operatorは、例えばリソースを動作させるために必要なソフトウェアのインストールや設定を行います。
Operatorは、KubebuilderやOperator Frameworkを活用すると効率的に実装できます。
Kubernetesの未来
標準化
Kubernetesは、CNCFによる開発と並行して、様々なレイヤでの標準化が進められています。
Open Container Initiative(OCI)
OCIは、2015年6月にコンテナ標準仕様を策定するために設立された団体で、Docker/Google/CoreOS/AWS/Red Hat/The Linux Foundationが参加しています。
2017年7月に策定されたOCI v1.0では、次の3つの仕様が規定されました。
- Runtime Specification v1.0: コンテナランタイム仕様
- Format Specification v1.0: コンテナイメージのフォーマット仕様
- Distribution Specification: v1.0: コンテナイメージの配布に関する仕様
Container Runtime Interface(CRI)
CRIは、前述の通り、kubeletとコンテナランタイム間のインターフェースに関する仕様です。
Container Storage Interface(CSI)
CSIは、Kubernetesなどのコンテナオーケストレーションエンジンとストレージを繋ぐためのインターフェースに関する仕様です。
現在はCNCFが中心となり、コンテナオーケストレーションエンジンを開発している様々なコミュニティが協力して、標準仕様の策定が行われています。
Container Network Interface(CNI)
CNIは、コンテナのネットワークインターフェースに関する仕様です。
CNIに準拠している代表的なソフトウェアは次の通りです。
- Project Calico
- Cilium
エコシステム
X as a Service (XaaS) on Kubernetes
代表例として、次のようなサービスがあります。
- Vitess: MySQL as a Service
- NATS: Queue as a Service
- Rook: Ceph as a Service
- Kubeflow: ML as a Service
Serverless on Kubernetes
代表例として、次のようなソフトウェアがあります。
- Knative
- OpenFaaS
- Kubeless
- Fission
Kubernets-native testbed
Kubernetesの様々なコンポーネントや、Kubernetesで動作するクラウドネイティブなソフトウェアやツールの動作を体験できるように、Kubernets-native testbedが公開されているので、使ってみると良いでしょう。
Discussion