クラスタ構成
下記2種類で構成されるクラスタ構成になっています。
- マスター(コントロールプレーン)
- ノード(Workerノード)
マスター(Control Plane)
クラスタ管理を担当するサーバの事です。SPOF(単一障害点)にならないように冗長化することもできます。受け皿としてAPIサーバーが提供されています。app.ymlで理想状態(デザイアードステイと)を記述してそれを読み込む。外部ネットワークに位置します。
マスターの担当作業
- 管理コマンドkubectl等のAPIクライアントからのリクエストを受けて、アプリケーションのデプロイ、スケール、コンテナのバージョンアップ等の全ての要求に対応する。
- アプリコンテナの配置先はマスターが自動的に決めて最適なノードにデプロイしてくれます。
- どの時間点を取っても常にapp.ymlで指定された数のポットが動くことを保証してくれます。もしあるワーカーのポッドが落ちたら別ワーカー上に自動で作成してくれます。
ノード
kubenetesがインストールされていれば物理でも仮想でも大丈夫。ノードの上にコンテナを載せます。アプリケーションの実行を担当する。ユーザーのアクセス数が増加した場合はコンテナ数を増やすことも必要ですが、ノード数を増やして対応する場合もあります。1から設定できて、最大ノード数は5000となっています。ノードの増設や削除はアプリの稼働中でも行えます。クラスタネットワークに位置します。
構成図
マスター側(コントロールプレイン側)
kube-apiserver
内部外部のやり取りをする。RESTリクエストを処理して状態を報告する。
kube-scheduler
アプリケーションをどのワーカーノードで実行するかスケジュールする役割です。
ワークロード専用のスケジュール機能。可用性、性能、キャパシティに重大な影響を及ぼす。コンテナの配置を管理します。
kube-controller-manager
etcdに保存されたデータを活用して理想状態と現状を比較し、違いがある場合は理想状態へ近づけようとします。
モニタリングした現在状態から希望状態への遷移を実行する。コンテナやポットの状態を監視して足りないものを補ってくれます。
etcd
k8sクラスタの全ての管理データ(状態)はここに保存される。分散キーバリューストア。信頼性が要求されるクリティカルなデータの保存とアクセスのために設計されている。以下のような情報が格納されています。
- kubenetesノード内にいくつのワーカーノードが管理されているのか。
- 各ワーカーのーどにどのアプリケーションが動いているのか。
- リソースはどれだけ使われているのか。
ノード側
Pod(ポッド)
コンテナで実行される範囲。kubenetesデプロイの最小単位です。ポッドの中には一つまたは複数のコンテナを持つことができます。
coredns
ポッドがサービス名からIPアドレスを得るために利用されている。
kubelet
kubenetesのエージェントが動いていてコントロールプレインとコミュニケーションを取れるようにします。
各ノードで動作する。具体的な役割は下記。
- マスターからの命令を受け取ります。
- ポッドとコンテナの実行
- ポッドとノードの状態をAPIサーバへ報告する。
- コンテナを検査するブローブの実行
- 内蔵するcAdvisorがメトリクスを集約して公開する。
kube-proxy
ノードのネットワークのルールを管理しています。kubenetesの設定をノード上のルーティングに実際に置き換える働きをしています。
各ノードで動作し、高可用性、低オーバーヘッドのロードバランシングを提供します。
その他
kubectl
k8sクラスタを操作するためのコマンドラインツールです。最も頻繁に利用されます。
kube-apiサーバーのクライアントとして働きます。
cloud-controller-manager
kubenetesがクラウドプロバイダーのリソースを管理できるようにするためのものです。
APIを通じてクラウドサービスと連携するコントローラでありクラウド各社によって実装される。
もし、ローカルやオンプレでkubenetesを使いたい場合は必要ない機能です。
動作の流れ
- KubernetesのAPIサーバーとして操作命令を受け取る。
- コンテナをポッドとしてスケジュールやクリーンナップする。
- ポッドのコントローラ機能と外部リソースのコントロール
レジストリ
クラスタの外側にあります。Dockerレジストリと同等のものです。
Dockerとの連携
KubernetesはDockerコンテナのランタイム環境です。Kubernetesを利用する際は必ず先にDockerをインストールしなければなりません。
Docker Engine側
containerd
様々なプラットフォーム上で動作する業界標準のコアコンテナのランタイムとして開発された。CRI(バージョン1.1から対応)を通じてコンテナの実行が要求されるとcontainerd-shimを生成する。
役割
コンテナホスト上で、イメージの転送、保管、コンテナの実行、ボリュームやネットワーク接続等のコンテナの完全なライフサイクルを管理できる。
containerd-shim
containerdとrunCの間を取り持ちます。runCがコンテナを立ち上げた後終了して代わりにcontainerd-shimがプロセスとして残ります。
OCI(Open Container Initiative)
runC
OCIに準じている。コンテナを立ち上げます。
Kubernetes側
kubelet
この記事へのコメントはありません。