Kubernetesコンテナクラウドプラットフォーム構築実践

[51CTO.com からのオリジナル記事] Kubernetes は、自動デプロイメント、大規模なスケーラビリティ、アプリケーション コンテナ管理をサポートする、Google のオープン ソース コンテナ オーケストレーション エンジンです。クラウドネイティブ テクノロジーの急速な台頭により、Kubernetes はアプリケーション コンテナ化プラットフォームの事実上の標準になりました。企業でますます好まれるようになり、生産現場でますます広く使用されるようになっています。

当社のコンテナ プラットフォームの構築は 2016 年に始まり、大まかに探索と予備調査、システム構築、プラットフォーム実装の 3 つの段階を経てきました。

次に、Kubernetes のネットワーク、ストレージ、クラスター管理、監視、運用と保守の観点から、コンテナ クラウド プラットフォームを構築する過程を共有し、皆さんに考えやインスピレーションを与えたいと思います。

1. Kubernetes ネットワーク

コンテナ ネットワーキングの開発は、現在、2 つの競争になっています。この 2 つは、実際には Google、CoreOS、Kuberenetes が主導する Docker の CNM と CNI を指します。まず、CNM と CNI はネットワーク実装ではなく、ネットワーク仕様とネットワーク システムであることを明確にする必要があります。 R&D の観点から見ると、それらは単なるインターフェースの集まりです。下層にフランネルを使用するか、カリコを使用するかは関係ありません。 CNM と CNI が重視しているのは、ネットワーク管理の問題です。

ネットワーク需要調査では、ビジネス部門が主に以下の点に懸念を抱いていることがわかりました。1. コンテナ ネットワークを物理ネットワークに接続する 2. 速いほど良い 3. 変更が少ないほど良い 4. リスク ポイントをできるだけ少なくする

コンテナ ネットワーク ソリューションは、プロトコル スタック レベル、トラバーサル形式、分離方式の 3 つの形式に大別できます。

プロトコル層: レイヤー 2 は比較的理解しやすく、従来のコンピュータ ルームや仮想化シナリオでよく使用されます。これは、ブリッジング ARP + MAC 学習に基づいています。最大の欠点は放送です。第 2 層のブロードキャストによってノードの規模が制限されるため、第 3 層 (純粋なルーティング転送) プロトコル スタックの第 3 層は、一般的に BGP に基づいており、コンピューター ルーム全体のルーティング状態を自律的に学習します。その最大の利点は IP の浸透性であり、つまり、この IP に基づくネットワークであれば、このネットワークを通過できるということです。明らかに、その規模は非常に有利であり、優れたスケーラビリティを備えています。

しかし、実際の展開プロセスでは、企業のネットワークが主に制御されます。たとえば、一部の企業ネットワークでは、セキュリティ上の理由から開発者が BGP を使用することを許可していなかったり、企業ネットワーク自体が BGP ではなかったりします。この場合、制限があります。レイヤー 2 とレイヤー 3 を組み合わせたプロトコル スタックの利点は、純粋なレイヤー 2 のスケーラビリティの問題と純粋なレイヤー 3 のさまざまな制限を解決できることです。特にクラウド VPC シナリオでは、VPC のノード間レイヤー 3 転送機能を利用できます。そのため、現在見られる Kubernetes デプロイメントの実際のネットワーク ソリューションには、2 層プラス 3 層のソリューションが数多く存在します。
交差フォーム:

これは実際の展開環境に非常に関連しています。交差フォームには、アンダーレイとオーバーレイの 2 種類があります。

アンダーレイ: より優れた制御可能なネットワーク シナリオでは、通常、アンダーレイを使用します。ベアメタルであろうと仮想マシンであろうと、ネットワーク全体（物理＋仮想）が制御可能であれば、コンテナネットワーク全体が直接通過できると簡単に理解できます。これはアンダーレイです。

オーバーレイ: オーバーレイはクラウド シナリオでは一般的です。オーバーレイの下には制御された VPC ネットワークがあります。 VPC の管轄外の IP または MAC が表示された場合、VPC はこの IP/MAC の通過を許可しません。このような場合は、Overlay メソッドを使用してこれを実行できます。
オーバーレイ ネットワークは物理ネットワークを仮想化し、リソースをプールするもので、クラウド ネットワーク統合を実現するための鍵となります。このアプローチでは、オーバーレイ ネットワークと SDN テクノロジーを組み合わせ、SDN コントローラーをオーバーレイ ネットワーク コントロール プレーンのコントローラーとして使用することで、ネットワークとコンピューティング コンポーネントの統合が容易になり、ネットワークをクラウド プラットフォーム サービスに変換するのに最適です。

分離方法:

分離方法は通常、VLAN と VXLAN の 2 種類に分けられます。

VLAN: VLAN はコンピュータ室で広く使用されていますが、実際には問題があります。つまり、入居者総数は制限されます。ご存知のとおり、VLAN の数には制限があります。

VXLAN: VXLAN は現在、より主流の分離方法です。スケーラブルで大規模であり、より優れた IP トラバーサル方式に基づいているためです。
従来のコンピュータ ルーム ネットワークとクラウド VPC ネットワーク アプリケーション シナリオにおける Kubernetes の一般的なネットワーク コンポーネント (Calico、contiv、flannel、Openshift SDN、カスタム ルーティング) を、プロトコル スタック レベル、トラバーサル形式、分離方法の観点から分析し、接続図を使用してそれらの関係を示します。

まず、従来のデータセンター ネットワークであっても、クラウド VPC ネットワークであっても、Overlay ソリューションは普遍的であることがわかります。透明性が優れているため、クラウド シナリオでより多く使用される可能性があります。

上の図では、赤い実線が従来のコンピューター ルーム ネットワークを指しており、ここで強調表示されています。アンダーレイ + 3 層ソリューションは、従来のコンピュータ ルーム ネットワークで非常に人気のあるソリューションです。優れたパフォーマンスを備えており、さまざまなシナリオで使用されています。アンダーレイ + レイヤー 2 + レイヤー 3 ソリューションは、クラウド VPC シナリオ (特にパブリック クラウド) の主流のソリューションでもあり、VPC のカスタム ルーティングを使用して転送を完了します。

緑の点線はクラウド化された VPC ネットワークを指しています。 Underlay+ 3 層ネットワークは、クラウド化された VPC シナリオでも限定的に使用できます。名前が示すように、制限付き使用では使用が許可されますが、クラウド ベンダーごとにネットワーク保護の定義が異なるため、すべてのプロバイダーが使用を許可しているわけではありません。たとえば、Calico ソリューションの BGP は AWS では簡単に実装できますが、Azure の VPC 自体が制御下にない IP の通過を許可しないため、Azure では許可されません。

黄色の実線はクラウド化された VPC ネットワークを示しています。クラウド化されたシナリオでは、オーバーレイ + レイヤー 2 またはレイヤー 3 がより一般的です。 Overlay の下には制御された VPC ネットワークがあり、管理と制御が容易になります。

もちろん、次の図に示すように、クラウド VPC シナリオにもいくつかの問題があります。

複数のテナント間のネットワーク分離の問題

K8s ではバージョン 1.3 からネットワーク ポリシー メカニズムが導入され、POD 間のインバウンドおよびアウトバウンドのアクセス ポリシーを実装できるようになりました。

ネットワーク ポリシーは、共通ラベルで識別されるポッドのグループに適用できます。これにより、フロントエンド ポッドとバックエンド ポッドを特定の「セグメント」ラベルで識別できる従来のセグメント化されたネットワークをエミュレートできます。ポリシーは、外部ソースからのトラフィックも含め、これらのセグメント間のトラフィック フローを制御します。ただし、すべてのネットワーク バックエンドが flannel などのポリシーをサポートしているわけではありません。現在、多くのメーカーがこの分野での研究を強化しており、多くの新しいソリューションがありますが、それを一つ一つ挙げることはできません。

クラスタ境界イングレス管理

Ingress は Kubernetes バージョン 1.2 でのみ登場しました。デフォルトでは、コンテナ アプリケーションはサービスの形式でサービスを提供しますが、サービスはクラスター内でのみ機能します。 Ingress を通じてサービスを公開することによってのみ、クラスター外部のクライアントにサービスを提供できます。

次の表は、一般的な Ingress コントローラを比較したものです。

Kubernetes ストレージ

K8s はもともとステートレス サービスの管理に使用されていましたが、ますます多くのアプリケーションが K8s プラットフォームに移行するにつれて、ストレージ リソースの管理が非常に重要な機能になりました。

Kubernetes でのストレージの使用は、主に次の側面に重点を置いています。

基本的なサービス構成ファイルの読み取り、暗号化キーの管理など。サービスの保存状況、データアクセスなど。異なるサービスやアプリケーション間でデータを共有します。おおよそ以下のようなシナリオがあります。

Kubernetes ストレージは、Kubernetes の一貫した哲学、つまり宣言型アーキテクチャに従って設計されています。同時に、できるだけ多くのストレージ プラットフォームとの互換性を確保するために、Kubernetes はツリー内プラグインの形式でさまざまなストレージ システムに接続し、ユーザーがこれらのプラグインを使用してビジネス ニーズに応じてコンテナーにストレージ サービスを提供できるようにします。 FlexVolume や CSI カスタマイズプラグインを使用するユーザーにも対応しています。 Docker Volume と比較して、より豊富で多様なストレージ機能をサポートします。

Kubernetes ストレージ プラグインの分析:

1. ツリー内プラグイン: ストレージコードはK8sと緊密に統合されており、結合が強すぎる

2. FlexVolume: ストレージ プラグインはホスト マシンにインストールされ、ホスト マシンのルート権限が必要です。

3. CSI 仕様: ストレージ コードを K8s から完全に分離する (バージョン 1.10 以上、CSI アタッチャのバージョン 0.2.0 を使用)

CSI 仕様は、プラグインの開発、保守、統合を大幅に容易にし、開発の見通しも良好です。

Kubernetes はストレージを管理するために 2 つのリソースを使用します。

PersistentVolume (略して PV): 管理者によって追加されたストレージの説明。ストレージ タイプ、ストレージ サイズ、アクセス モードを含むグローバル リソースです。そのライフサイクルは Pod から独立しています。たとえば、それを使用している Pod が破壊された場合、PV には影響がありません。

PersistentVolumeClaim (略して PVC): PV のリクエストを記述する名前空間内のリソースです。リクエスト情報には、ストレージ サイズ、アクセス モードなどが含まれます。

PV は利用可能なストレージ リソースと見なすことができ、PVC はストレージ リソースの需要です。 PVC は、Pod の要件に応じて適切な PV を Pod に自動的にバインドします。 PV と PVC の関係は、次の図に示すライフサイクルに従います。

PV モードには静的モードと動的モードがあります。静的 PV モードは NFS、FC、および ISCSI を管理し、動的 ​​PV モードは glusterfs、Cinder、Ceph RBD、Vsphere、ScaleIO、AWS、および Azure を管理します。静的 PV では管理者が PV を作成および管理する必要がありますが、動的 PV はシステムによって自動的に生成され、PVC にバインドされます。

Kubernetes でのイメージ管理について簡単に説明します。本番環境ではさまざまなバージョンやアプリケーションのイメージが多数存在しており、イメージ管理も比較的重要なリンクです。

イメージのマルチテナント権限管理:

1. 異なるテナントのイメージは互いに分離する必要がある

2. テナントによって、読み取り/書き込み、読み取り専用、アップロード、ダウンロードなどのイメージに対する権限が異なります。

3. 画像ライブラリは、画像のクエリ、更新、削除などの機能を提供します。

クロスリージョンおよびマルチデータセンターのイメージ管理の場合、イメージライブラリのリモートレプリケーション管理では次の点に注意する必要があります。

1. 複数のデータセンターや複数の地域にまたがる複数のサイトがある環境では、マルチリージョンイメージのダウンロード効率を向上させるために、メインイメージライブラリとサブイメージライブラリの少なくとも 2 レベルのイメージライブラリが必要です。

2. イメージリポジトリ間の準リアルタイム増分同期

Kubernetes クラスター管理

実稼働システムでは、Kubernetes の複数のクラスターの管理には主に次の作業が含まれます。

1. サービスの運用と保守

2. 集中構成

3. 容量の拡張とアップグレード

4. リソース割り当て

まず、マルチクラスタのスケジューリング管理についてお話ししましょう。

1. Kubernetes のスケジューリング戦略は、大きく分けてグローバル スケジューリング戦略とランタイム スケジューリング戦略の 2 種類に分けられます。

2. ノードの分離と回復NODE 拡張;ポッドの動的な拡張とスケーリング。

3. アフィニティにより、近接展開を実現し、ネットワーク機能を強化し、通信における近接ルーティングを実現し、ネットワーク損失を削減できます。アンチアフィニティは主に高い信頼性を考慮したものであり、インスタンスは可能な限り分散されます。

4. マイクロサービスの依存関係、起動順序の定義

5. 部門間のアプリケーションの混在禁止

6. APIゲートウェイとGPUノードアプリケーションの排他的使用

マルチクラスタ管理におけるアプリケーションの弾力的なスケーリング管理:

1. 手動拡大・縮小：業務量の変化を事前に把握

2. CPU使用率に基づく自動拡張と縮小: バージョンv1.1ではコントローラHPAが導入され、PODはCPUリソース使用要求を設定する必要があります。

3. カスタムビジネス指標に基づく自動拡張と縮小: バージョンv1.7ではHPAが再設計され、コンポーネントが追加されました。これはHPA v2と呼ばれます。

実際のアプリケーションでは、HPA にはまだ多くの欠陥があります。多くのメーカーは、独自の監視システムを使用してビジネス指標を監視し、自動的な生産能力拡張を実現しています。

Kubernetes マルチクラスターのチューニング:

主な困難は3つあります。

1 つ目は、リソースをどのように割り当てるかです。ユーザーがマルチクラスター展開を選択すると、システムは各クラスターのリソース使用量に基づいて各クラスターに割り当てられるコンテナーの数を決定し、各クラスターに少なくとも 1 つのコンテナーがあることを確認します。クラスターが自動的にスケーリングされると、コンテナもこの比率に従って作成され、リサイクルされます。

2つ目は障害の移行です。クラスター コントローラーは主に、複数のクラスターの自動スケーリングや、クラスターに障害が発生した場合のコンテナーの移行を解決するために使用されます。コントローラーはクラスター内の複数のノードを定期的に検出します。複数の障害が発生した場合、サービスの信頼性の高い運用を確保するために、クラスター コンテナーの移行操作がトリガーされます。

3 つ目は、ネットワークとストレージ間の相互接続です。コンピュータ室間のネットワークを相互接続する必要があるため、vxlan ネットワーク ソリューションを使用して実装し、ストレージも専用回線で相互接続します。コンテナのイメージ リポジトリは Harbor を使用し、複数のクラスター間で同期戦略が設定され、各クラスターには独自のドメイン名解決があり、異なるイメージ リポジトリに解決されます。

K8s クラスターのマスターノードは高可用性です。 Kubernetes クラスターの中核はマスター ノードであることはわかっていますが、現在、デフォルトではマスター ノードは 1 つしかありません。マスターノードに問題が発生すると、Kubernetes クラスターは「麻痺」し、クラスター管理と Pod スケジューリングは実装されなくなります。そのため、後に、高可用性アーキテクチャで設計できるマスターノード、etcd を含む、1 マスター複数スレーブ アーキテクチャが登場しました。

フェデレーション クラスター フェデレーション アーキテクチャ

クラウド コンピューティング環境では、サービス効果の範囲は、通常、近いものから遠いものまでさまざまです。つまり、同じホスト (ホスト、ノード)、同じアベイラビリティ ゾーン (アベイラビリティ ゾーン) 内のホスト間、同じリージョン (リージョン) 内のアベイラビリティ ゾーン間、同じサービス プロバイダー (クラウド サービス プロバイダー) のリージョン間、およびクラウド プラットフォーム間です。 K8s は、同じリージョン内のネットワーク パフォーマンスが K8s のスケジューリングとコンピューティング ストレージ接続の要件を満たすことができるため、同じリージョン内に単一のクラスターを持つように設計されています。 Cluster Federation は、高いビジネス可用性を実現するために、リージョンやサービス プロバイダー全体に K8s クラスター サービスを提供するように設計されています。

Federation はバージョン 1.3 で導入されました。 federation/v1beta1 API は、DNS ベースのサービス検出の機能を拡張します。 DNS を使用することで、POD はクラスター間でサービスを透過的に解決できます。

バージョン1.6はフェデレーションリソースのカスケード削除をサポートし、バージョン1.8は5000ノードのクラスタ、クラスタフェデレーションV2をサポートすると主張しています。

現在の問題:

1. ネットワーク帯域幅とコストの増加

2. 複数のクラスター間の分離が弱まる

3. 成熟度が不足しており、生産現場で正式に適用されていない

4. Kubernetesの監視と運用・保守

監視システムの場合、一般的な監視ディメンションには、リソース監視とアプリケーション監視が含まれます。リソース監視とは、ノードとアプリケーションのリソース使用状況を指します。コンテナ シナリオでは、ノード、クラスター、およびポッドのリソース使用率にまで拡張されます。アプリケーション監視とは、内部アプリケーション インジケーターの監視を指します。たとえば、アプリケーションのオンライン ユーザーの数をリアルタイムでカウントし、ポートを通じて公開して、アプリケーションのビジネス レベルの監視とアラートを実装します。では、Kubernetes では、監視オブジェクトはどのようなエンティティに分類されるのでしょうか?

システムコンポーネント

Kubernetes クラスターの組み込みコンポーネントには、apiserver、controller-manager、etcd などがあります。

静的リソースエンティティ

主にノードのリソースステータス、カーネルイベントなどを参照します。

動的リソースエンティティ

主に、Deployment、DaemonSet、Pod など、Kubernetes 内の抽象的なワークロードのエンティティを指します。

カスタムアプリケーション

主に、アプリケーション内でカスタマイズする必要がある監視データと監視インジケーターを指します。

さまざまなコンテナ クラウド監視ソリューションの比較:

Prometheus モニタリング:

注目すべき主なポイントは 2 つあります。

• クエリAPIのカプセル化
• 設定ファイルの配布

運用保守を考える---開発と運用保守の統合

運用と保守について考える---高可用性の問題

• Ocp プラットフォーム:

1. 負荷分散ルーター高可用性クラスター: 2 ノード

2. EFK 高可用性クラスター: 3 ES ノード + n F ノード

3. イメージウェアハウスの高可用性クラスター: 2 つのイメージウェアハウス

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

1. 登録センター高可用性クラスタ（Eureka）: 3

2. 構成センター高可用性クラスタ: 3

3. ゲートウェイ高可用性クラスタ: 2

4. 主要なマイクロサービスはすべて高可用性クラスタです

運用と保守を考える---高同時実行性の問題

• Ocp プラットフォーム:

1. バックエンド マイクロサービス (Pod) の柔軟な拡張を構成します。 K8 の弾力的な拡張性と数秒で実行される Docker コンテナの起動により、ユーザーの継続的な成長をサポートできます。

2. 同時実行性が高くなった場合にリソースを緊急に拡張できるように、事前に 20% のリソースを予約します。

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

1. 主要リンクマイクロサービスのフューズスレッド数の増加：主要業務の同時応答能力を向上します。

2. 回路遮断と電流制限により、重要でないリンク マイクロサービスを低下させたり、シャットダウンしたりします。

3. サーキットブレーカーメカニズム: 高同時実行シナリオにおけるコンテナクラウドのフォールトトレランス機能を向上させ、マイクロサービスの連鎖障害や雪崩効果を防ぎ、システムの可用性を向上させます。

• ミドルウェア:

1. 現在使用中のクラスターに加えて、事前にコールドスタンバイクラスターを追加します。

2. 高同時実行シナリオが発生しそうな場合、緊急水平拡張を実行できます。

最後に、コンテナクラウドへの道の概要

1. ビジネスレベル: 大企業ではビジネスの安定性と継続性に対する要件が比較的高いため、コンテナ化の進化の道筋は、エッジビジネスからコアビジネスへ、単純なアプリケーションから複雑なアプリケーションへと向かう必要があります。具体的には、まずWebフロントエンドでのコンテナ化移行を検討し、その後バックエンドビジネスに移行していくことになります。

2. 技術レベル: 現在、ネイティブ Docker には、サービス検出、負荷分散、コンテナライフサイクル管理、コンテナ間ネットワーク、ストレージなどの点でまだ多くの欠点があります。サードパーティメーカーが提供する多くのオープンソースソリューションと商用バージョンには独自の特徴があり、どれが優れているかを見分けるのは困難です。ユーザーがどの製品を選択するかに関係なく、信頼性と柔軟性は慎重に考慮する必要がある 2 つの重要な要素です。

3. 費用対効果を考慮する：コンテナ化にかかるコストと将来の利益のバランスを総合的に考慮します。

4. 既存のハードウェアの負荷容量を考慮すると、コンテナ化は万能薬ではありません。より高い同時スループット、ベアメタル上での直接実行、システムチューニングによるパフォーマンスの向上を必要とする一部のビジネスでは、コンテナ化は最適な選択肢ではない可能性があります。

5. 常に最新情報を入手し、学び続けて変化を受け入れることを常に意識してください。この方法でのみ、プラットフォームの欠点を把握し、継続的に改善してより良い製品を作成することができます。

生産の実践においては、基盤を強化し、コンテナ クラウド プラットフォームに基づいて製品を継続的に改善し、エコシステムを構築することによってのみ、未来をコントロールし、何千マイルも離れた戦いに勝つことができます。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]