Kubernetes: 開発者も理解する必要がある運用と保守の知識

この記事はWeChatの公開アカウント「Java Art」から転載したものです。この記事を転載する場合は、Java Art の公開アカウントにご連絡ください。

Docker と Kubernetes の関係は何ですか?これは、Kubernetes に初めて触れるときに私たち全員が抱く疑問かもしれません。 Kubernetes とは何でしょうか?

Kubernetes は、コンテナ クラスターの自動展開や自動拡張・縮小などの機能を実装するために使用されるコンテナ クラスター オーケストレーション管理システムです。 Docker はアプリケーションを実行するためのコンテナ テクノロジを提供しますが、Kubernetes 自体はアプリケーションを実行するためのコンテナを提供するのではなく、コンテナの管理を担当します。

Docker と Kubernetes の関係を理解すると、Kubernetes を学ぶ前に Docker を学ぶ必要がある理由がわかります。これは、Spring Boot と Spring Cloud をより深く学ぶ前に Spring フレームワークを学ぶのと同じです。まだDockerを知らないという方は、まずは前回の記事「開発者も知っておきたいDockerの運用・保守知識」を読んでみてください。

開発者として、コンテナ技術を理解する必要があるのはなぜでしょうか?これは運用と保守が学ぶべきことではないでしょうか?開発者として、コンテナ テクノロジーを完全に理解することによってのみ、適切なテクノロジーを選択し、Kubernetes コンテナ サービスにデプロイされたアプリケーションを開発する際に注意すべき問題を把握することができます。運用と保守がコードを理解しておらず、開発が Kubernetes を理解していない場合、Kubernetes へのサービスの移行で発生するさまざまな問題を誰が解決できるでしょうか?

Kubernetesについて

Kubernetes を学習するには、まず Kubernetes アーキテクチャを理解し、いくつかの「概念」を理解し、次に構成ファイルを理解する必要があります。設定ファイルは初心者にとって最も理解しにくい部分なので、「Kubernetes in Action Chinese Edition」という本を読んで、例をステップバイステップで実行しながら、設定ファイル内の各種類の役割や各設定項目の役割を理解することをお勧めします。

Kubernetes は利用可能なすべての物理マシンを管理します。 Alibaba Cloud Container Service Kubernetes を例にとると、Kubernetes は多数の ECS インスタンスの管理を担当します。このため、Kubernetes クラスターを作成するときに、十分な数の ECS インスタンス (少なくとも 2 つ) を購入する必要があります。新しく購入した ECS インスタンスを Kubernetes クラスターに追加し、Kubernetes で管理することもできます。

開発者とオペレーターは、アプリケーションがどの ECS インスタンスにデプロイされているかを知る必要はありません。アプリケーションを実行するために必要な CPU、メモリ、その他のリソースを指定するだけで済みます。 Kubernetes は、要件を満たすノード (ECS) を計算し、ノード (ECS) 上のイメージ リポジトリからアプリケーション イメージをプルし、コンテナを作成してコンテナを実行し、コンテナのライフサイクル全体を監視します。 Kubernetes が管理するすべてのノード (ECS) を 1 台の大きな物理マシンとして考えることができます。この大規模な物理マシンの CPU とメモリは、すべてのノード (ECS) の合計です。

(「Kubernetes in Action」よりの写真)

上の図に示すように、開発者はアプリケーションをイメージに構築し、そのイメージをリモート イメージ リポジトリにプッシュするだけで済みます。次に、アプリケーション イメージを実行するために必要なリソースや、イメージの取得元などを記述した構成ファイルを作成する必要があります。アプリケーションは、kubectl を使用して Kubernetes が提供する API を呼び出すことで Kubernetes にデプロイできます。

Kubernetes は 2 種類のノードで構成されています。

(Kubernetes in Action からの画像)

1 つはマスター ノードで、クラスター全体の制御と管理を担当します。高可用性を実現するには、マスター ノードにもクラスターの展開が必要です。一部のコンポーネントはマスターノードにデプロイされます。これらのコンポーネントは、単一のマスター ノード上で実行することも、レプリカを介して複数のマスター ノードにデプロイして高可用性を実現することもできます。たとえば、Reft プロトコルに基づくデータ一貫性ストレージ サービスである etcd、当社に提供されている Kubernetes API サービス、アプリケーションのデプロイメントをスケジュールするための Scheculer コンポーネント、クラスター機能を実行するための Controller Manager コンポーネントなどです。今のところ、あまり詳しく説明せずに、これらのコンポーネントを簡単に理解することができます。

もう 1 つは、ユーザーが実際にデプロイしたアプリケーションを実行する作業ノードです。

Alibaba Cloud からマネージド Kubernetes サービスを購入すると仮定すると、マスターノードは Alibaba Cloud によってホストされ、ワー​​カーノードは購入した ECS インスタンスになります。クラスター内のワーカーノードの数は、ECS インスタンスの数です。

ワーカーノードはコンテナを実行するマシンです。各ワーカーノードは、デプロイするアプリケーションを実行するためのコンテナを実行するだけでなく、アプリケーション サービスの実行、監視、管理を担当するいくつかのコンポーネントも実行します。 Docker、Kubelet、Kube-proxy など。私たちはすでに Docker に精通しています。 Kubelet は、マスター ノードの Kubernetes API サービスと通信し、マスター ノードが配置されているワーカー ノードのコンテナーを管理する役割を担います。 Kube-proxy は、コンポーネント間のネットワーク トラフィックの負荷分散を担当します。

上の図は、これまでの Kubernetes に関する理解に基づいて描かれたアプリケーション デプロイメント フローチャートです。

• 1. 開発者はローカルマシン上でアプリケーションイメージを構築します。
• 2. 開発者はローカル アプリケーション イメージをイメージ リポジトリにプッシュします。
• 3. 開発者は、アプリケーションを実行するための記述ファイル（yaml 構成ファイル）を作成します。
• 4. 開発者は kubectl を使用して Kubernetes API を呼び出し、アプリケーション記述ファイルを Kubernetes に送信します。
• 5. スケジューラ コンポーネントは、記述ファイルに従ってアプリケーションをデプロイするように作業ノードをスケジュールします。
• 6. 作業ノードでは、コンテナ ランタイムがイメージ リポジトリからイメージをプルし、コンテナを作成し、コンテナを実行します。

実際のプロジェクトを展開する際に、ネットワークとコンテナに関する部分が最も懸念され、理解しにくい場合があります。例えば、Kubernetes を使用せずに SSD リソースを必要とするアプリケーションをデプロイする場合、まず SSD を購入してサーバーにマウントします。 Kubernetes を使用する場合、アプリケーションをデプロイするために SSD を備えたノードのみを選択するように Kubernetes に指示する必要があります。ネットワークとコンテナ ボリュームの内容は依然として非常に複雑です。この記事では詳しく紹介しません。次回以降の記事で紹介させていただきます。もちろん、著者は現時点ではあまり理解していないので、簡単な理解と使用方法のみを説明します。

知っておくべき概念

名前空間: テスト環境リソースや本番環境リソースなどの異なるリソースを区別するために使用されます。もちろん、ラベルを使用して区別することもできます。名前空間が指定されていない場合は、デフォルトで default が使用されます。デフォルト以外の名前空間を使用する場合は、kubectl を使用してシークレットまたは ServiceAccount を作成するときに、名前空間を明示的に指定する必要があります。

ノード: ノードは、Alibaba Cloud ECS などの実際のマシンまたは仮想マシンです。

Pod: Pod は、Kubernetes によって作成またはデプロイされる最小の基本単位です。 Pod は、1 つ以上のアプリケーション コンテナー、ストレージ リソース、独立したネットワーク IP、およびコンテナーの実行方法を管理および制御するためのポリシー オプションをカプセル化します。

(Kubernetes in Action からの画像)

上の図に示すように、Pod に複数のコンテナが含まれている場合、これらのコンテナは常に同じワーカー ノード上で実行され、複数のワーカー ノードにまたがることはありません。たとえば、Java プログラムをデプロイする場合、1 つの Pod で Java プログラムの複数のコンテナを実行できます。ポッドは密結合されたアプリケーションをカプセル化できます。フロントエンドとバックエンドを一緒にデプロイするなど、リソースを共有できる複数のコンテナで構成する必要があります (この例は不適切です)。 Java マイクロサービス アプリケーションを開発する場合、通常、Pod は 1 つのコンテナーのみを実行するため、始めたばかりのときはこれらの概念についてあまり心配する必要はありません。

サービス: サービスは、ポッドを論理的にグループ化した抽象的な概念です。この Pod のグループには、通常はラベルとセレクターを介してサービスからアクセスできます。例えば：

 APIバージョン: v1
種類: サービス
メタデータ:
名前: デモ サービス
  名前空間: sit
仕様:
  セレクタ：
    アプリ: デモSRV
    環境: 座る
  ポート:
    - プロトコル: TCP
      ポート: 80
      ターゲットポート: 8080

app が demo-srv、env が sit である Pod のグループは、セレクターを通じて一致します。この Pod グループは、サービス demo-srv-service に対応します。もっと簡単に理解するために、Java プログラムをデプロイし、Pod が Java プログラムのコンテナーを 1 つだけ起動するとします。この場合、複数の Java プログラムの起動は複数の Pod に対応し、この Pod のグループは同じサービスに対応します。

ReplicationController: ReplicationController (略して RC) は、ユーザー定義の Pod レプリカの数が変更されないことを保証します。ユーザー定義の範囲内で、たとえば、Java プログラムのデプロイメントのクラスターの数を 3 に指定した場合、Pod の数が 3 を超えると (たとえば、手動で開始した場合)、RC は追加の Pod を終了します。 Pod の数が 3 未満の場合 (たとえば、メモリ オーバーフローが原因)、RC は定義された範囲内に常に収まるように新しい Pod を作成します。

ReplicaSet: ReplicaSet (RS とも呼ばれる) は、RC のアップグレード バージョンです。 RS と RC の唯一の違いはセレクターのサポートですが、ここでは詳しく紹介しません。

デプロイメント: デプロイメントは、ポッドとレプリカセットの宣言的な更新を提供します。デプロイメントでは、希望するターゲット状態を記述するだけで、デプロイメント コントローラーがポッドとレプリカセットの実際の状態をターゲット状態に変更するのに役立ちます。

 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
名前: デモ SRV デプロイメント
  名前空間: sit
仕様:
  # レプリカの数、実行する `Pod` の数
  レプリカ: 3
  # ラベルマッチングを使用したセレクター
  セレクタ：
    一致ラベル:
      アプリ: デモSRV
  テンプレート：
    メタデータ:
      # ラベル
      ラベル:
        アプリ: デモSRV
        環境: 座る
    仕様:
      #コンテナ、複数のコンテナを指定すると、1つの `Pod` で複数のコンテナが実行されます。
      コンテナ:
        -名前: デモsrv
          画像: registry.cn-shenzhen.aliyuncs.com/wujiuye/demo-srv

DaemonSet: 各ノード (物理マシンまたは仮想マシン) でアプリケーションの Pod が 1 つだけ実行されるようにします。たとえば、Alibaba Cloud が実装するログ収集は、Pod に対応する各ノード上でログを収集するためのアプリケーション コンテナを実行します。

ネットワーク通信

ポッド間のネットワーク通信:

Kubernetes クラスター内のすべての Pod は同じ共有ネットワーク アドレス空間内にあるため、各 Pod は他の Pod の IP アドレスを介して相互にアクセスできます。これは、それらの間に NAT ゲートウェイが存在しないことも意味します。 2 つの Pod が相互にネットワーク パケットを送信すると、両方の Pod は、パケット内の送信元 IP として相手の実際の IP アドレスを認識します。

2 つの Pod が単一のワーカー ノードにスケジュールされているか、異なるワーカー ノードにスケジュールされているかに関係なく、またノード間の実際のネットワーク トポロジに関係なく、これらの Pod 内のコンテナーは LAN 上のコンピューターのように通信できます。

サービス間のネットワーク通信:

Kubernetes サービスは、機能的に同一の Pod のセットに対して、単一の変更されないアクセス ポイントを提供します。サービスが存在する間、その IP アドレスとポートは変更されません。クライアントは IP アドレスとポート番号を通じて接続を確立し、これらの接続はサービスを提供する任意の Pod にルーティングされ、負荷分散が実現されます。この方法では、クライアントはサービスを提供する個々の Pod のアドレスを知る必要がないため、これらの Pod はいつでもクラスターから作成または削除できます。

demo-srv と demo-cap という 2 つのマイクロサービスを持つ既存のプロジェクトがあるとします。次に、これら 2 つのサービスを Alibaba Cloud Container Service Kubernetes にデプロイします。コンソールのサービス リスト ページでは、これら 2 つのサービスにクラスター IP があることがわかります。これら 2 つのサービスにデプロイされている Pod の数や Pod の変更方法に関係なく、他のサービスはこのクラスター IP を介して背後にある Pod にアクセスできます。もちろん、背後にある Pod にアクセスすることでも負荷分散が実現されます。

このため、マイクロサービス用に開発するサービス検出はサービスに基づいているため、アプリケーションで負荷分散を実装することは冗長です。

タイプ：

• ClusterIP: クラスターの内部 IP を通じてサービスを公開します。この値を選択した場合、サービスには Kubernetes クラスター内でのみアクセスできます。
• NodePort: 各ノードの IP と静的ポート (NodePort) を通じてサービスを公開します。 NodePort サービスは、自動的に作成される ClusterIP サービスにルーティングされます。リクエストに応じて: NodePort サービスにはクラスター外部からアクセスできます。
• LoadBalancer: Alibaba Cloud が提供するロードバランサーを使用すると、サービスを外部に公開できます。外部ロード バランサは、NodePort サービスおよび ClusterIP サービスにルーティングできます。

これでこの記事は終わりです。 Kubernetes について学ぶべき知識ポイントは数多くありますが、開発者としては、いくつかの詳細にあまり注意を払わないかもしれません。この記事で紹介した知識ポイントは、開発者が習得すべきものだと考えています。ネットワークとコンテナ ボリュームの展開について詳しく学習することをお勧めします。ネットワークはサービス間の呼び出しに関連し、コンテナ ボリュームは日記の印刷とファイルの保存に関連します。 Alibaba Cloud Container Service を使用すると、ファイルに出力するのではなく、Alibaba が提供する日記サービスを使用して日記を収集できます。ただし、永続的なストレージ サービスが必要な場合は、コンテナー ボリュームを理解する必要があります。

概念が理解できない場合は、公式ドキュメントを参照してください: http://docs.kubernetes.org.cn

もっと詳しく知りたい場合は、「Kubernetes in Action」の中国語版を読むことをお勧めします。