[[431760]]

Kubernetes とは何ですか?

Kubernetes は、サーバー上のコンテナ化されたアプリケーションの管理を容易にするために設計された、Google のオープンソースの分散コンテナ管理プラットフォームです。

KubernetesはK8Sと略されます。なぜそう呼ばれるのでしょうか？KとSはKubernetesの最初と最後の文字であり、KとSの間には8つの文字があるため、K8Sと略されます。また、Kubernetesは少し複雑なため、K8Sという略称が一般的に使用されています。

Kubernetesは、コンテナオーケストレーションツールであると同時に、コンテナ技術を基盤とした全く新しい分散アーキテクチャソリューションです。Dockerをベースとし、アプリケーションの作成、アプリケーションのデプロイ、サービスのプロビジョニング、動的なスケーリング、アプリケーションのアップデートといった一連のサービスを提供することで、コンテナクラスタ管理の利便性を向上させます。

Kubernetesの出現の理由

下の画像をご覧ください。MySQL、Redis、Tomcat、Nginxなどの設定情報が含まれています。ここにデータをインストールするには、それぞれ手動で一つずつインストールする必要があります。ただし、一つしかないので、それも可能のようです。少し面倒ですが、処理が遅くなることはありません。

しかし、技術の進歩とビジネスニーズの高まりにより、単一のサーバーではもはや日常的な要件を満たすことができなくなりました。ますます多くの企業がクラスター環境やマルチコンテナのデプロイメントを求めています。もし現状のまま、マシンを一つずつ個別にデプロイしていたら、運用チームはマシンのデプロイに一日中費やし、大変なことになります。場合によっては、あるステップでたった一つのエラーが発生するだけで最初からやり直さなければならなくなり、非常にフラストレーションがたまることになります…下の図をご覧ください。

次のマシンにデプロイする場合:

 3つのNginxインスタンス
5 つの Redis インスタンス
7 台の ZooKeeper マシン
4つのTomcatインスタンス
6 つの MySQL インスタンス
5 ユニット - JDK
 10台のサーバー

一つ一つデプロイしていくのは非常に面倒で、終わりのない作業になるでしょう。もしAlibabaのマシンが2万台あったら、その場でスタッフを辞めさせなければならないでしょうか？Kubernetesは、まさにこうした状況の解決に役立ちます。Kubernetesはコンテナ管理とアプリケーションのデプロイをより便利にし、反復作業を削減し、アプリケーションのデプロイの自動化と障害の自己修復を可能にします。

さらに、Kubernetes (K8S) がマイクロサービスに対して優れたサポートを提供し、システム負荷の変化に応じてマイクロサービスのレプリカを調整できる場合、K8S 固有の弾性スケーリング メカニズムにより、突然のトラフィックの急増にも効果的に対応できます。

コンテナオーケストレーションツールの比較

Docker-Compose

Docker-Composeはコンテナを管理するために使用され、コンテナマネージャーに似ています。起動する必要があるコンテナやアプリケーションが多数ある場合、手動で管理するのは非常に時間がかかります。Docker-Composeを使用すると、単一の設定ファイルですべてを処理できます。ただし、Docker-Composeは現在のホストマシン上のDockerコンテナのみを管理でき、他のサーバー上のサービスを管理することはできません。つまり、単一マシン環境です。

Dockerスウォーム

Docker Inc. が開発した Docker Swarm は、クラスター上の Docker コンテナを管理するためのツールです。Docker-Compose のシングルノードアーキテクチャの限界を克服しています。Docker Swarm は、コンテナの起動、ステータスの監視、コンテナサービスがクラッシュした場合の新規コンテナの再起動を支援し、サービスの継続的な提供を保証します。また、サービス間の負荷分散もサポートしています。これらは Docker-Compose ではサポートされていない機能です。

Kubernetes

KubernetesはDocker Swarmと同じ役割を果たしており、コンテナ分野において同様の役割を担っています。しかし、両者にはいくつかの違いもあります。KubernetesはGoogle独自の製品であり、豊富な実用経験とホストマシンでのテストを経て、非常に成熟しています。そのため、Kubernetesはコンテナオーケストレーション分野のリーダーになりつつあります。Kubernetesの設定柔軟性、信頼性、そして幅広いコミュニティサポートはDocker Swarmを凌駕しています。Googleのオープンソースプロジェクトとして、Google Cloud Platform全体と連携して動作します。

Kubernetesの責任

1. コンテナの自動展開とレプリケーション
2. いつでもコンテナのサイズを拡大または縮小できます
3. コンテナはグループにまとめられ、コンテナ間の負荷分散が提供されます。
4. リアルタイム監視：タイムリーな障害検出と自動交換

K8Sの基本概念

下の図は、3台のホストマシンを含むKubernetes (K8S) クラスターを示しています。各四角形は物理仮想マシンを表しています。これら3台の物理マシンが完全なクラスターを構成しており、役割に基づいて2つのタイプに分類できます。

• 1つ目はKubernetesマスターサーバーで、クラスター全体を管理します。Kubernetesマスターサーバーはクラスター内のすべてのノードを管理し、コンテナの作成、自動デプロイ、自動公開などの機能をこれらのノードに送信します。外部ソースからのすべてのデータはKubernetesマスターによって受信され、配信されます。
• もう一つの種類はノードです。ノードは独立した物理マシンまたは仮想マシンです。各ノードには、Kubernetes固有の非常に重要な概念であるポッドが含まれています。ポッドはKubernetesにおける最も重要かつ基本的な概念です。

ポッド

• Pod は Kubernetes における制御の最小単位であり、プロセスです。
• Pod は、コンテナ化された環境内のアプリケーション層の「論理ホスト」として見ることができます。つまり、複数の「コンテナ」を含むコンテナのコンテナとして理解できます。
• 通常、Pod 内の複数のコンテナ アプリケーションは密接に結合されており、Pod はノード上で作成、起動、または破棄されます。
• 各ポッドは「Pause」と呼ばれる特別なコンテナを実行し、その他のコンテナは「アプリケーションコンテナ」と呼ばれます。これらのアプリケーションコンテナは、Pauseコンテナのネットワークスタックとボリュームマウントを共有します。
• Pod の内部コンテナ ネットワークは相互接続されており、各 Pod には独自の独立した仮想 IP があります。
• ポッドは完全なアプリケーションまたはモジュールのデプロイメントであり、同じポッド内のコンテナーはロケールを通じて簡単に相互に通信できます。
• Podのライフサイクルはレプリケーションコントローラーによって管理されます。Podはテンプレートを使用して定義され、実行のためにノードに割り当てられます。Podを含むコンテナの実行が終了すると、Podも終了します。

もっと分かりやすい例えで言うと、ポッドを豆の鞘、コンテナをその中の豆と考えることができます。これは共生関係です。

[[431766]]

ポッドの中には一体何が入っているのでしょうか?

• 一部の小規模企業では、PodはRedis、MySQL、Tomcatなどの様々なコンテナを含む完全なアプリケーションです。単一のPodをデプロイすることは、完全なアプリケーションをデプロイすることと同じです。複数のPodをまとめてデプロイすることで、クラスターが形成されます。これがPodの最も基本的な利用方法です。
• もう 1 つのユースケースは、Pod 内で 1 種類のコンテナのみを提供することです (たとえば、Pod 内に Tomcat のみをデプロイする)。

Pod 内のコンテナの具体的な展開方法は、プロジェクトの特性とリソースの割り当てに基づいて適切な選択を行うことで決定されます。

一時停止コンテナ:

Pauseコンテナ（インフラストラクチャコンテナとも呼ばれる）は、initポッドとして機能する基本コンテナです。他のポッドはPauseコンテナからフォークされ、どのポッドにも不可欠です。ポッド内のアプリケーションコンテナは同じリソースを共有します。

1. PID 名前空間: Pod 内のさまざまなアプリケーションは、他のアプリケーションのプロセス ID を確認できます。
2. ネットワーク名前空間: Pod 内の複数のコンテナが同じ IP アドレスとポート範囲にアクセスできます。
3. IPC 名前空間: Pod 内の複数のコンテナは、通信に System V IPC または POSIX メッセージ キューを使用できます。
4. UTS名前空間: ポッド内の複数のコンテナは単一のホスト名を共有します。ボリューム（共有ストレージボリューム）
5. ポッド内の各コンテナは、ポッド レベルで定義されたボリュームにアクセスできます。

上の図では、pauseコンテナがない場合、NginxとGhost、そしてPod内のコンテナは、それぞれ独自のIPアドレスとポート番号を使用して通信する必要がありました。pauseコンテナを使用すると、Pod全体をひとまとまりのものとして見ることができるため、NginxとGhostはlocalhostを使用して直接相互にアクセスできます。両者の違いはポート番号のみです。これは一見単純なように見えますが、実際には多くの低レベルのネットワーク技術が使用されています。興味のある方は、ご自身で詳細をご確認ください。

サービス

Kubernetesでは、各Podに固有のIPアドレスが割り当てられますが、Pod同士が直接やり取りすることはできません。ネットワーク通信には、Serviceという別のコンポーネントが必要です。

サービスとはサービスを意味します。Kubernetesにおけるサービスの主な機能は、複数の異なるホスト上のポッドを接続し、それらが相互に通信できるようにすることです。

サービスはドメイン名と考えることができますが、同じサービスを持つPodのクラスターはそれぞれ異なるIPアドレスを持ちます。サービスはラベルセレクターを使用して定義されます。

• サービスにはドメイン名に似た固有の名前が与えられ、さらに仮想IPアドレスとポート番号が割り当てられます。これらのサービスには内部ネットワークからのみアクセスできます。外部ネットワークからアクセスしたり、外部サービスを提供したりする場合は、パブリックIPアドレスとNodePort、または外部ロードバランサーを指定する必要があります。

NodePort を使用して外部アクセスを提供するには、各ノード上のホストの実際のポートを開くだけで済み、ノードのクライアントを介して内部サービスにアクセスできるようになります。

ラベル

ラベルは通常、キーと値のペアの形式で様々なオブジェクトに付与されます。ラベルは説明的なタグであり、非常に重要な役割を果たします。コンテナをデプロイする際には、ラベルに基づいて操作対象のPodを検索・絞り込む必要があります。ラベルは各Podのエイリアスと考えることができます。ラベルに名前を付けることでのみ、Kubernetesマスターノードは対応するPodを見つけて操作を実行できます。

レプリケーションコントローラ

1. マスターノードに配置されたこの兄弟ノードは、主にPodの数を監視します。例えば、下のノードに同じ属性を持つPodが3つ必要で、現在2つしかない場合、ReplicationControllerはPodが2つしかないことを認識すると、定義したルールに従って自動的に追加のレプリカを作成し、それをノードに配置します。
2. ReplicationControllerはPodをリアルタイムで監視することもできます。Podが応答しなくなった場合、そのPodは削除されます。必要に応じて、ReplicationControllerは自動的に新しいPodを作成します。
3. Kubernetesは、RCで定義されたラベルを使用して対応するPodインスタンスをフィルタリングし、そのステータスと数をリアルタイムで監視します。インスタンス数が定義されたレプリカ数より少ない場合、RCで定義されたPodテンプレートに従って新しいPodが作成され、その後、Podインスタンス数が事前に設定された目標数に達するまで、適切なノードでこのPodの実行が開始されるようにスケジュールされます。

K8S 全体アーキテクチャ

• Kubernetes は、クラスター内のマシンをマスター ノードとワーカー ノードのグループに分割します。
• マスターノードは、etcd、APIServer、ControllerManager、Schedulerという一連のクラスタ管理プロセスを実行します。後者の3つのコンポーネントはKubernetesの中央制御センターを構成します。これらのプロセスは、リソース管理、Podのスケジューリング、柔軟なスケーリング、セキュリティ制御、システム監視、クラスタ全体のエラー修正などの管理機能を実装し、すべて自動的に実行されます。
• Node.jsノード上でkubelet、kube-proxy、dockerを実行することで、真のKubernetes（K8S）テクノロジーソリューションが実現します。これらは、ローカルノード上のPodのライフサイクル管理とサービスプロキシ機能の実装を担います。

ユーザーがKubectl経由でReplicationControllerの作成リクエストを送信します。このリクエストはAPIサーバー経由でetcdに書き込まれます。APIサーバーをリッスンしているControllerManagerは作成リクエストを検出し、慎重な分析の結果、現在のクラスター内に対応するPodインスタンスが存在しないことを検出します。その後、ControllerManagerはReplicationControllerテンプレート定義に基づいてPodオブジェクトを迅速に作成し、APIサーバー経由でetcdに書き込みます。

スケジューラがこれを検出すると、すぐに複雑なスケジューリングプロセスを実行し、新しいポッドに適したノードを選択します。少なくとも、これでポッドにはアイデンティティが与えられました！これはかなり面倒です。そして、その結果をAPIサーバー経由でetcdに書き込みます。その後、ノード上で実行されているKubeletプロセスがAPIサーバー経由でこの生まれたばかりの赤ちゃん、つまり「ポッド」を検出し、その特性に応じて起動し、ポッドの寿命が尽きるまでその寿命を懸命に管理します。

次に、Kubectlを使用して、このPodにマッピングされた新しいService作成リクエストを送信します。ControllerManagerは、ラベルを介して関連付けられたPodインスタンスを照会し、Serviceのエンドポイント情報を生成して、APIサーバーを介してetcdに書き込みます。次に、すべてのノードで実行されているProxyプロセスは、APIサーバーを介してServiceオブジェクトと対応するエンドポイント情報を照会およびリッスンし、ServiceからバックエンドPodへのアクセスのためのトラフィック転送機能を実現するためのソフトウェアロードバランサーを構築します。

kube-proxy: マルチホスト通信の仲介役として機能するプロキシです。前述の通り、Serviceはホスト間およびコンテナ間のネットワーク通信を実装しており、技術的にはkube-proxyによって実現されます。ServiceはPodを論理的にグループ化し、その基盤となる通信はkube-proxyによって処理されます。

kubelet: Kubernetesコマンドの実行に使用され、Kubernetesのコアコマンドでもあります。Kubernetes関連の命令を実行し、現在のNode上のPodのライフサイクル管理（作成、変更、監視、削除など）を担います。また、Kubeletは現在のNodeのステータス情報を定期的にAPIサーバーに報告します。

etcd: クラスター内のすべてのリソースオブジェクトの永続的なストレージとして使用されます。APIサーバーは、etcdの操作をカプセル化するAPIを提供します。これらのAPIは、主にリソースオブジェクトの操作とリソースの変更の監視のためのインターフェースです。

APIサーバー：リソースオブジェクトを操作するためのエントリポイントを提供します。他のコンポーネントは、APIサーバーが提供するAPIを介してリソースデータを操作する必要があります。関連するリソースデータに対して「フルクエリ」と「変更監視」を実行することで、関連するビジネス機能をリアルタイムで完了できます。

スケジューラ: スケジューラは、クラスター ノード間でのポッドのスケジュールと割り当てを担当します。

コントローラーマネージャー：クラスターの内部管理および制御センターであり、Kubernetesクラスター内の障害検出と復旧の自動化を主に担います。例えば、ポッドの複製と削除、エンドポイントオブジェクトの作成と更新、ノードの検出、管理、ステータス監視はすべてコントローラーマネージャーによって処理されます。

要約

Kubernetesの基礎的な説明はこれで終わりです。もし気に入っていただけたら、ぜひ「いいね！」とフォローをお願いします。Dockerと比べて、Kubernetesはより成熟した機能を備えています。Googleによる徹底的なテストを経て生まれたKubernetesは、比較的成熟した完成度の高いシステムです。

この記事はWeChat公式アカウント「Mu Xiaonong」から転載したものです。