初心者でも理解できます。 Kubernetesは実はとてもシンプルです

Kubernetes は、過去 2 年間で最も注目され、最もよく知られているテクノロジーです。ソフトウェア エンジニアに強力なコンテナ オーケストレーション機能を提供し、開発と運用および保守の境界を曖昧にし、大規模な分散システムやプロジェクトの開発、管理、保守を容易にします。

[[253138]]

この記事では、まず Kubernetes の背景、Kubernetes が依存するテクノロジー、そのアーキテクチャと設計哲学について簡単に紹介し、最後にいくつかの重要な概念と実装の原則について説明します。

Kubernetesの背景

現在、本番環境で広く使用されているオープンソース プロジェクトである Kubernetes は、コンテナ アプリケーションの展開、拡張、管理を自動化するオープンソース システムとして定義されています。分散ソフトウェアのコンテナのグループを、管理と検出が容易な論理ユニットにパッケージ化します。

Kubernetes はギリシャ語で「操舵手」を意味します。もともとは Google のソフトウェア エンジニア数名によって設立され、同社の内部 Borg および Omega プロジェクトから大きな影響を受けました。その設計の多くはボーグから借用されたもので、ボーグの欠陥も改良された。

Kubernetes は現在、Cloud Native Computing Foundation (CNCF) のプロジェクトであり、多くの企業が分散システムを管理するためのソリューションとなっています。

Kubernetes がコンテナ オーケストレーションの分野を支配する前は、Compose や Swarm など、コンテナ オーケストレーション ソリューションが実際に数多く存在していました。しかし、大規模で複雑なクラスターを運用・保守する場合、これらのソリューションは基本的に Kubernetes に置き換えられています。

Kubernetes はパッケージ化されたアプリケーション イメージをオーケストレートするため、コンテナ テクノロジの開発とマイクロサービス アーキテクチャにおける複雑なアプリケーション関係がなければ、使用する適切なアプリケーション シナリオを見つけることは困難です。

そこでここでは、Kubernetes の 2 つの主要な「依存関係」であるコンテナ テクノロジーとマイクロサービス アーキテクチャについて簡単に紹介します。

コンテナ技術

Docker はすでにコンテナ テクノロジーの事実上の標準となっています。前回の記事「Docker コアテクノロジーと実装の原則」では、Docker の実装は主に Linux 名前空間、cgroups、UnionFS に依存していることを紹介しました。

これにより、開発者はアプリケーションと依存関係をポータブル コンテナーにパッケージ化できるため、アプリケーションを環境から独立して実行できるようになります。

Docker を使用すると、分離されたプロセス、ネットワーク、マウント ポイント、ファイル システムを備えた環境を実装し、ホスト マシンにリソースを割り当てることができます。

これにより、同じマシン上で複数の異なる Docker コンテナを実行できるようになります。どの Docker プロセスもホスト マシンの依存関係を気にする必要がなく、イメージの構築中に依存関係のインストールとコンパイルをそれぞれ完了します。

これが、Docker が Kubernetes プロジェクトの重要な依存関係である理由です。

マイクロサービスアーキテクチャ

今日のソフトウェアが特に複雑ではなく、処理する必要のあるピーク時のトラフィックが特に大きくない場合、バックエンド プロジェクトの展開では、仮想マシンにいくつかの単純な依存関係をインストールし、展開するプロジェクトをコンパイルして実行するだけで済みます。

しかし、ソフトウェアがますます複雑になるにつれて、完全なバックエンド サービスは単一のサービスではなく、異なる責任と機能を持つ複数のサービスで構成されるようになります。

サービス間の複雑なトポロジ関係と、単一のマシンではパフォーマンス要件を満たすことができないため、ソフトウェアの展開、運用、保守が非常に複雑になり、大規模なクラスターの展開と運用が緊急に必要になります。

概要: Kubernetes の出現は、コンテナ オーケストレーション市場を支配するだけでなく、これまでの運用および保守方法も変えています。開発と運用・保守の境界が曖昧になるだけでなく、DevOps の役割も明確になります。

すべてのソフトウェア エンジニアは、Kubernetes を使用して、サービス間のトポロジ関係、オンライン ノードの数、リソースの使用状況を定義し、従来は複雑だった水平拡張、ブルーグリーン デプロイメントなどの運用および保守操作を迅速に実装できます。

Kubernetes の設計コンセプトとアーキテクチャ

デザインコンセプト

まず、Kubernetes の設計コンセプトのいくつかを紹介しましょう。これらのキーワードは、Kubernetes が設計時に選択した内容を理解するのに役立ちます。

ここでは、宣言型、明示的なインターフェース、非侵入型、移植性の設計選択が何をもたらすかを順番に紹介します。

宣言的

エンジニアは宣言型プログラミングを命令型プログラミングと常に比較してきましたが、これらはまったく異なるプログラミング手法です。

私たちが最もよく目にするのは、実は命令型プログラミングです。命令型プログラミングでは、特定の効果や目標を達成するために実行する必要のある命令を記述する必要があります。一般的なプログラミング言語である Go、Ruby、C++ はすべて、開発者に命令型プログラミング手法を提供します。

Kubernetes では、YAML ファイルを直接使用してサービスのトポロジとステータスを定義できます。

 APIバージョン: v1
種類: ポッド
メタデータ:
名前: RSSサイト
  ラベル:
    アプリ: ウェブ
仕様:
  コンテナ:
    -名前: フロントエンド 
      画像: nginx
      ポート:
        - コンテナポート: 80
    -名前: RSSリーダー
      画像: nickchase/rss-php-nginx:v1
      ポート:
        - コンテナポート: 88

この宣言的なアプローチにより、ユーザーの作業負荷が大幅に軽減され、開発効率が大幅に向上します。

これは、宣言型アプローチによって必要なコードを簡素化し、開発者の作業を軽減できるためです。開発に命令型のアプローチを使用すると、構成はより柔軟になりますが、作業量が増えます。

 SELECT * FROM posts WHERE user_id = 1 AND title LIKE   'こんにちは％' ;

SQL は実際には、開発者が必要なデータを指定できるようにする一般的な宣言型の「プログラミング言語」です。

Kubernetes の YAML ファイルにも同じ原則が適用されます。望ましい最終状態を Kubernetes に伝えると、現在の状態からの移行に役立ちます。

Kubernetes が命令型プログラミングを使用してインターフェースを提供する場合、エンジニアはコードを使用して、特定の状態を達成するために必要な操作を Kubernetes に伝える必要がある場合があります。ステータスと結果に重点を置く宣言型プログラミングと比較して、命令型プログラミングはプロセスを重視します。

要約すると、Kubernetes の宣言型 API は、実際にはクラスターの予想される動作状態を指定します。

したがって、不整合が発生した場合、指定された YAML ファイルを通じてオンライン クラスターの状態を移行できます。

水平トリガー システムと同様に、システムが対応するイベントを見逃した場合でも、最終的には現在の状態に基づいて適切なアクションが自動的に実行されます。

明示的なインターフェース

Kubernetes の 2 番目の設計仕様は、実際には、内部のプライベート インターフェースが存在せず、すべてのインターフェースが明示的に定義されており、コンポーネント間の通信に使用されるインターフェースはユーザーに対して明示的であり、直接呼び出すことができるというものです。

Kubernetes インターフェースがエンジニアの複雑なニーズを満たせない場合は、既存のインターフェースを使用してより複雑な機能を実装する必要があります。現時点では、Kubernetes のこの設計はカスタム要件の障害にはなりません。

非侵襲的

Kubernetes では、ユーザー (エンジニア) のニーズに最大限応え、エンジニアの作業負荷やタスクを軽減し、柔軟性を高めるために、エンジニアに非侵入的なアクセス方法を提供しています。

各アプリケーションまたはサービスがイメージにパッケージ化されると、アプリケーション内のコードを変更することなく、Kubernetes でシームレスに使用できるようになります。

Docker と Kubernetes は、アプリケーションを囲む 2 つのレイヤーのようなもので、どちらもアプリケーションのコンテナ化とオーケストレーション機能を提供します。

Docker および Kubernetes クラスターで実行するためにアプリケーションを変更する必要はありません。これは、Kubernetes が設計時に非侵入性を選択した最大の利点です。同時に、非侵入型アクセスも、ほぼすべてのアプリケーションやサービスが考慮しなければならないポイントです。

携帯性

マイクロサービス アーキテクチャでは、多くの場合、すべてのビジネス処理サービスをステートレス サービスにします。

以前はメモリに保存されていたデータ、セッション、その他のキャッシュは、Redis や ETCD などのデータベースに保存されるようになりました。マイクロサービス アーキテクチャでは、ビジネスを分割し、サービス間に明確な境界を引く必要があるため、ステートフル サービスはアーキテクチャの水平移行に障害をもたらすことがよくあります。

ただし、ステートフル サービスは不可欠です。各基本サービスまたはビジネス サービスを、コンピューティングのみを担当するプロセスに変換します。

ただし、揮発性キャッシュと永続データを保存するには、他のプロセスも必要です。 Kubernetes は、このようなステートフル サービスに対しても優れたサポートを提供します。

Kubernetes では、基盤となるストレージの違いを隠すために、永続ボリュームと永続ボリューム要求の概念が導入されています。現在、Kubernetes は次のタイプの永続ボリュームをサポートしています。

これらの異なる永続ボリュームは、開発者が宣言した永続ボリューム要求によって異なるサービスに割り当てられます。

上位層では、すべてのサービスが永続ボリュームに触れる必要はありません。 Persistent Volume Claim によって取得されたボリュームを直接使用することだけが必要です。

建築

Kubernetes は非常に伝統的なクライアント サーバー アーキテクチャに従っており、クライアントは RESTful インターフェースを介して、または kubectl を使用して直接 Kubernetes クラスターと通信します。

実際には両者の間に大きな違いはありません。後者は、Kubernetes によって提供される RESTful API をカプセル化して提供します。

各 Kubernetes クラスターは、一連のマスター ノードと一連のワーカー ノードで構成されます。マスターノードは主に、クラスターのステータスを保存し、Kubernetes オブジェクトのリソースを割り当ててスケジュールする役割を担います。

マスター

クラスターの状態を管理するマスターノードとして、クライアント要求の受信、コンテナ実行の調整、制御ループの実行を行い、クラスターの状態をターゲット状態に移行することを主な役割とします。マスターノードは 3 つのコンポーネントで構成されます。

API サーバーは、ユーザーからのリクエストを処理する役割を担います。その主な機能は、クラスターの状態を表示するための読み取り要求や、クラスターの状態を変更するための書き込み要求など、外部に RESTful インターフェースを提供することです。また、etcd クラスターと通信する唯一のコンポーネントでもあります。

コントローラー マネージャーは一連のコントローラー プロセスを実行し、ユーザーの期待状態に応じて、バックグラウンドでクラスター全体のオブジェクトを継続的に調整します。サービスの状態が変化すると、コントローラーはその変化を検出し、ターゲット状態への移行を開始します。

*** スケジューラは、Kubernetes で実行されているポッドに対してデプロイされたワーカー ノードを実際に選択します。ユーザーのニーズに応じて、Pod を実行するためのリクエストに最も適したノードを選択します。 Pod をスケジュールする必要があるたびに実行されます。

ワーカー

他のワーカーノードの実装は比較的簡単です。主に kubelet と kube-proxy の 2 つの部分で構成されます。

kubelet はノード上のメインサービスです。 API サーバーから新しいまたは変更された Pod 仕様を定期的に受信し、ノード上の Pod とコンテナの正常な動作を保証します。また、ノードがターゲット状態に移行することも保証します。ノードは引き続きホストのヘルス ステータスをマスター ノードに送信します。

各ノードで実行される別のプロキシ サービス kube-proxy は、ホスト サブネットの管理を担当し、サービスを外部に公開することもできます。その原理は、複数の分離されたネットワーク内の正しいポッドまたはコンテナにリクエストを転送することです。

Kubernetes 実装の原則

これまでに、Kubernetes に関する基本的な知識と理解が得られ、Kubernetes アーキテクチャの概要も理解できました。次に、Kubernetes におけるいくつかの重要な概念と実装の原則を紹介します。

物体

Kubernetes オブジェクトはシステム内の永続的なエンティティです。これらのオブジェクトを使用して、クラスターの状態を表します。これらのオブジェクトは次のことを記述できます。

これらのオブジェクトは、クラスター内で実行する必要があるアプリケーション、それらが要求する最小および最大のリソース制限、および再起動、アップグレード、およびフォールト トレランスの戦略を記述します。

作成された各オブジェクトは、クラスターの状態の変更を表します。これらのオブジェクトは、実際にはクラスターの望ましい状態を記述します。 Kubernetes は、指定した目的の状態に基づいて、現在のクラスターの状態を継続的にチェックし、移行します。

型デプロイメント構造体{
    metav1.TypeMeta `json: ",inline" `
    metav1.ObjectMeta `json: "metadata,omitempty" protobuf: "bytes,1,opt,name=metadata" ` 
 
    仕様 DeploymentSpec `json: "spec,omitempty" protobuf: "bytes,2,opt,name=spec" `
    ステータス DeploymentStatus `json: "status,omitempty" protobuf: "bytes,3,opt,name=status" `
 }

各オブジェクトには、仕様 (Spec) とステータス (Status) を記述する 2 つのネストされたオブジェクトが含まれています。オブジェクトの仕様は、実際に期待するターゲット ステータスです。

状態はオブジェクトの現在の状態を表します。この部分は通常、Kubernetes システム自体によって提供および管理され、クラスター自体を監視するためのインターフェースです。

ポッド

Pod は Kubernetes における最も基本的な概念です。これは、Kubernetes オブジェクト モデルで作成またはデプロイできる最小かつ最も単純な単位でもあります。

アプリケーション コンテナー、ストレージ リソース、独立したネットワーク IP アドレス、およびその他のリソースをパッケージ化して、最小の展開単位を表します。

ただし、各 Pod では複数のコンテナが実行されている場合があります。これは、Pod が元々、複数のプロセスを調整して、非常にまとまりのあるサービス ユニットを構築できるように設計されていたためです。これらのコンテナはストレージとネットワークを共有し、非常に便利に通信できます。

コントローラ

***今回紹介したいのはKubernetesのコントローラーです。これらは実際に Pod インスタンスの作成と管理に使用されます。クラスター内でレプリケーション、パブリッシング、ヘルスチェック機能を提供できます。これらのコントローラーは、Kubernetes クラスターのマスター ノード上で実行されます。

Kuberentes の kubernetes/pkg/controller/ ディレクトリには、公式が提供するいくつかの一般的なコントローラーが含まれています。次の関数を通じて実行する必要があるすべてのコントローラーを確認できます。

 func NewControllerInitializers(loopMode ControllerLoopMode) map[string]InitFunc {
    コントローラー := map[文字列]InitFunc{}
    コントローラ[ "エンドポイント" ] = startEndpointController
    コントローラ[ "replicationcontroller" ] = startReplicationController
    コントローラ[ "podgc" ] = startPodGCController
    コントローラ[ "resourcequota" ] = startResourceQuotaController
    コントローラ[ "namespace" ] = startNamespaceController
    コントローラ[ "serviceaccount" ] = startServiceAccountController
    コントローラ[ "garbagecollector" ] = startGarbageCollectorController
    コントローラー[ "デーモンセット" ] = startDaemonSetController
    コントローラ[ "ジョブ" ] = startJobController
    コントローラ[ "デプロイメント" ] = startDeploymentController
    コントローラー[ "レプリカセット" ] = startReplicaSetController
    コントローラ[ "horizo​​ntalpodautoscaling" ] = startHPAController
    コントローラー[ "中断" ] = startDisruptionController
    コントローラ[ "statefulset" ] = startStatefulSetController
    コントローラ[ "cronjob" ] = startCronJobController
    // ... 
 
リターンコントローラー
}

これらのコントローラーは、コントローラー マネージャーが起動すると実行されます。クラスターのステータスの変化を監視して、クラスター内の Kuberentes オブジェクトのステータスを調整します。次の記事では、いくつかの一般的なコントローラーの実装原則を紹介します。

要約する

以上、その誕生の背景と、それを支える主要技術について学びました。同時に、Kubernetes のアーキテクチャ設計も紹介しました。マスター ノードは、クライアント要求の処理とノードのスケジュール設定を担当します。最後に、Kuberentes の非常に重要な概念であるオブジェクト、ポッド、コントローラーについて説明しました。