Kubernetesをゼロから学ぶ

Kubernetes はコンテナ オーケストレーションの王者になりました。これは、クラスターの拡張、ローリング アップグレードとロールバック、エラスティック スケーリング、自動修復、サービス検出などの複数の機能と機能を備えたコンテナー ベースのクラスター オーケストレーション エンジンです。

この記事では、Kubernetes の概要と、Kubernetes について話すときに何について話しているのかを簡単に紹介します。

Kubernetes アーキテクチャ

マクロ的な観点から見ると、Kubernetes の全体的なアーキテクチャには、マスター、ノード、etcd が含まれます。

マスターはメインノードであり、Kubernetes クラスター全体の制御を担当します。 API サーバー、スケジューラ、コントローラなどのコンポーネントが含まれます。これらすべては、データを保存するために etcd と対話する必要があります。

• API サーバー: 主にリソース操作の統一されたエントリ ポイントを提供し、etcd との直接的なやり取りを保護します。機能には、セキュリティ、登録、検出が含まれます。
• スケジューラ: 特定のスケジューリング ルールに従って、ポッドをノードにスケジュールする役割を担います。
• コントローラー: リソースが期待どおりの動作状態にあることを確認するリソース制御センター。
• ノードは、クラスター全体に計算能力を提供する動作ノードです。実行中のコンテナ、kubelet、kube-proxy など、コンテナが実際に実行される場所です。
• kubelet: 主なタスクには、コンテナのライフサイクルの管理、cAdvisor による監視、ヘルスチェック、ノード ステータスの定期的なレポートなどがあります。
• kube-proxy: 主にサービスを使用して、サービス/エンドポイントの変更を監視し、負荷分散を更新しながら、クラスター内でのサービス検出と負荷分散を提供します。

デプロイメントの作成から始めましょう

デプロイメントは、後で紹介するポッドをオーケストレーションするために使用されるコントローラー リソースです。ここでは、デプロイメントを例に、デプロイメント リソースを作成するプロセスでアーキテクチャ内の各コンポーネントが何を実行するかを確認します。

まず、kubectlはデプロイメントを作成するリクエストを開始します

• apiserver はデプロイメントを作成するためのリクエストを受け取り、関連するリソースを etcd に書き込みます。後続のすべてのコンポーネントは、同様の方法で apiserver/etcd と対話します。
• デプロイメントコントローラはリソースの変更をリスト/監視し、レプリカセットを作成するためのリクエストを開始します。
• replicaSet コントローラーはリソースの変更をリスト/監視し、Pod 作成リクエストを開始します。
• スケジューラは、バインドされていない Pod リソースを検出し、一連のマッチングとフィルタリングを通じて、バインドする適切なノードを選択します。
• Kubeletは、ノード上に新しいPodを作成する必要があることを検出し、Podの作成とその後のライフサイクル管理を担当します。
• kube-proxy は、サービス検出や負荷分散などのネットワーク ルールを含む、サービス関連のリソースの初期化を担当します。

この時点で、Kubernetes の各コンポーネント間の分業と調整により、デプロイメント リクエストの作成から各特定の Pod の通常の操作までのプロセス全体が完了します。

ポッド

Kubernetes の多くの API リソースの中で、Pod は最も重要かつ基本的なものであり、最小のデプロイメント単位です。

最初に考えるべき質問は、なぜ Pod が必要なのかということです。 Pod は、「非常に親密な」関係を持つコンテナ向けに設計されたコンテナ設計パターンであると言えます。 war パッケージのサーブレット コンテナーのデプロイやログ収集などのシナリオが考えられます。これらのコンテナは、多くの場合、ネットワーク、共有ストレージ、共有構成を共有する必要があるため、Pod の概念があります。

Pod の場合、異なるコンテナがインフラ コンテナを介して外部ネットワーク空間を統一的に識別し、たとえばホスト マシン上のディレクトリに相当する同じボリュームをマウントすることで、自然にストレージを共有できます。

コンテナオーケストレーション

コンテナオーケストレーションはKubernetesの得意分野なので、それを理解する必要があります。 Kubernetes には、ステートレス アプリケーションをオーケストレーションするためのデプロイメント、ステートフル アプリケーションをオーケストレーションするための StatefulSet、デーモンをオーケストレーションするための DaemonSet、オフライン サービスをオーケストレーションするための Job/CronJob など、オーケストレーション関連の制御リソースが多数あります。

最も広く使用されている展開を例に挙げてみましょう。デプロイメント、レプリケートセット、および Pod 間の関係は、階層化された制御関係です。簡単に言えば、レプリカセットはポッドの数を制御し、デプロイメントはレプリカセットのバージョン プロパティを制御します。この設計パターンは、数量によって制御される水平スケーリングとバージョン属性によって制御される更新/ロールバックという、最も基本的な 2 つのオーケストレーション アクションの基礎も提供します。

水平スケーリング

横方向の展開が非常にわかりやすいです。レプリカセットによって制御される Pod コピーの数を、たとえば 2 から 3 に変更するだけで、水平拡張が完了します。それ以外の場合は水平収縮です。

更新/ロールバック

更新/ロールバックは、レプリカセット オブジェクトの必要性を反映します。たとえば、3 つのアプリケーション インスタンスのバージョンを v1 から v2 に変更する必要がある場合、v1 バージョンのレプリカセットによって制御される Pod コピーの数は 3 から 0 に徐々に変更され、v2 バージョンのレプリカセットによって制御される Pod の数は 0 から 3 に変更されます。デプロイメントの下に v2 バージョンのレプリカセットのみが存在すると、更新が完了します。ロールバックは逆のアクションを実行します。

ローリングアップデート

上記の例では、アプリケーションを更新すると、Pod が常に 1 つずつアップグレードされ、少なくとも 2 つの Pod が使用可能になり、最大 4 つの Pod がサービスを提供していることがわかります。この「ローリング アップデート」の利点は明らかです。新しいバージョンにバグが発生した場合でも、残りの 2 つの Pod は引き続きサービスを提供でき、迅速かつ簡単にロールバックできます。

実際のアプリケーションでは、RollingUpdateStrategy を構成することでローリング アップデート戦略を制御できます。 maxSurge はデプロイメント コントローラーが作成できる新しい Pod の数を示し、maxUnavailable はデプロイメント コントローラーが削除できる古い Pod の数を示します。

Kubernetes でのネットワーク

コンテナ オーケストレーションの実行方法がわかったところで、コンテナはどのようにして相互に通信するのでしょうか。

ネットワーク通信に関しては、Kubernetes にはまず次の 3 つの基本が必要です。

• ノードとポッドは通信できる
• ノードのポッドは互いに通信できる
• 異なるノード間のポッドは通信できる

つまり、異なる Pod は cni0/docker0 ブリッジを介して相互に通信し、Node は cni0/docker0 ブリッジを介して Pod にアクセスします。異なるノード間で Pod 通信を実装する方法は多数あり、現在より一般的な Flannel VXLAN/HostGW モードも含まれます。 Flannel は etcd を通じて他のノードのネットワーク情報を取得し、ノードのルーティング テーブルを作成して、最終的に異なるノード間のホスト間通信を可能にします。

マイクロサービス: サービス

以下の内容を理解する前に、まず非常に重要なリソース オブジェクトであるサービスを理解する必要があります。

なぜサービスが必要なのでしょうか?マイクロサービスでは、Pod はインスタンスに対応し、Service はマイクロサービスに対応します。サービス呼び出しのプロセスでは、サービスの出現によって次の 2 つの問題が解決されます。

Pod の IP は固定されていません。ネットワーク通話に固定でない IP を使用することは現実的ではありません。サービス呼び出しは、異なるポッドに対して負荷分散する必要があります。

サービスはラベル セレクターを通じて適切なポッドを選択し、ポッドの負荷分散リストであるエンドポイントを構築します。実際の使用では、通常、同じマイクロサービスの Pod インスタンスに app=xxx のようなラベルを付け、マイクロサービスに対して app=xxx のラベル セレクターを持つ Service を作成します。

Kubernetes でのサービス検出とネットワーク呼び出し

前述の「3 つのリンク」ネットワーク基盤により、マイクロサービス アーキテクチャのネットワーク呼び出しが Kubernetes でどのように実装されるかがわかります。

この部分は、実際には「Kubernetes がサービス検出を実装する方法」で非常に明確に説明されています。詳細については上記の記事を参照してください。ここで簡単に紹介します。

サービス間通話

1 つ目は、東西トラフィック コール、つまりサービス間のコールです。この部分には主に、ClusterIP モードと DNS モードという 2 つの呼び出しモードが含まれます。

ClusterIP はサービスの一種です。このモードでは、kube-proxy は iptables/ipvs を通じてサービス用の VIP (仮想 IP) の形式を実装します。負荷分散された方法でサービスの背後にあるポッドにアクセスするには、VIP にアクセスするだけで済みます。

上の図は ClusterIP を実装する 1 つの方法を示しています。また、userSpace プロキシ モード (基本的には使用されません) と ipvs モード (パフォーマンスが向上) も含まれます。

DNSモードはわかりやすいです。 ClusterIP モードのサービスの場合、ClusterIP アドレスを指す service-name.namespace-name.svc.cluster.local の A レコードがあります。したがって、一般的な使用では、サービス名を直接呼び出すことができます。

サービス外アクセス

North-South トラフィック、つまり Kubernetes クラスターにアクセスするための外部リクエストには、主に nodePort、loadbalancer、Ingress の 3 つの方法が含まれます。

NodePort もサービスの一種です。 iptables を通じて、ホスト上の特定のポートを呼び出すことで、基盤となるサービスにアクセスできるようになります。

ロードバランサは、パブリック クラウドによって提供されるロード バランサを通じて実装される別のタイプのサービスです。

100 個のサービスにアクセスするには、100 個の nodePort/loadbalancer を作成する必要がある場合があります。 Ingress の機能である統合された外部アクセス レイヤーを介して内部 Kubernetes クラスターにアクセスしたいと考えています。 Ingress は、さまざまなルーティング ルールを通じてさまざまなバックエンド サービスを一致させる、統合アクセス レイヤーを提供します。 Ingress は「サービスのサービス」と考えることができます。 Ingress は、その機能を完了するために、多くの場合、nodePort および loadbalancer と組み合わせて実装されます。

これまで、Kubernetes の関連概念、大まかな仕組み、Kubernetes でマイクロサービスが実行される方法について簡単に理解してきました。したがって、Kubernetes について人々が話しているのを聞くと、私たちは彼らが何について話しているのかが分かります。