記事の著者: Ana Cunha、Jose Yapur、
開発者擁護者、アマゾン ウェブ サービス
記事翻訳者：鄭裕斌
Amazonクラウドテクノロジーシニアデベロッパーエバンジェリスト
前回の記事「Picturesocial | 実際の開発: 15 分でアプリをコンテナ化する方法」では、コンテナとアプリケーションのコンテナ化に必要な手順について説明しました。海に浮かぶ輸送用コンテナに家を置くような、どこに配置するかを考えずにコンテナを作成するのは、ロマンチックでもあり、恐ろしいことでもあります。安全で快適な生活を送りたいなら、電気、水道、ガス、食料、ゴミ収集…そしてできれば社会活動も必要です。
この記事では、海上に浮かぶコンテナを安全で快適な家に変えるのに役立つコンテナ コンパイル ツールである Kubernetes について学びます。これは Picturesocial アーキテクチャの非常に重要な部分です。
Picturesocial には複数の API があり、メンテナンス、展開、開発のさまざまな段階で API を互いに分離しておきたいと考えています。したがって、コンテナ化されたアーキテクチャを使用することにしました。
実際にはそれほど複雑ではなく、コンテナとコンテナ コンパイラを使用することを意味するだけです。Container Orchestrator は、オーケストレーションに必要なすべてのコンテナ、コンテナ レプリカ、ネットワーキング、ストレージ、インフラストラクチャ コンポーネントを処理します。コンテナ オーケストレーターにとって、現在最も人気のあるものは Kubernetes です。これは、活発なコミュニティ、継続的かつ効果的な技術サポート、そして豊かなエコシステムによるものです。
私たちは Kubernetes k8s と呼んでいますが、これはオープンソースのコンテナ オーケストレーターであり、そのエコシステムは急速かつ広範囲に開発されています。Kubernetes は、開発者がコンテナのスケーリングと障害処理を管理するのに役立つだけでなく、次のことも役立ちます。
サービスの検出と負荷分散:コンテナーとインフラストラクチャー間のネットワーク トラフィックの負荷分散、および削除されるコンテナーの新しいコピーまたは失敗したコンテナーの検出が可能になります。
自動化されたデプロイとロールバック:コンテナのデプロイ方法、更新の処理方法、更新、インフラストラクチャの障害、またはコンテナのエラーによるダウンタイムから保護する方法を選択できます。
自動パッケージ化: Kubernetes は、設定された制限に従って利用可能なコンピューティング能力を使用、最適化、調整します。
自己修復:コンテナーに障害が発生した場合、Kubernetes はコンテナーが正常になるまで再起動するか、コンテナーを削除して新しいコンテナーを作成します。
独自の Kubernetes クラスターを最初からデプロイして運用するのは簡単ではなく、Kubernetes、Linux、仮想化、ネットワーク、セキュリティ、その他のテクノロジーについて深く理解する必要があります。したがって、Amazon Cloud Technology は開発者に Amazon Elastic Kubernetes (Amazon EKS) サービスを提供します。これはフルマネージドの Kubernetes ソリューションであり、動作環境のセキュリティを確保しながら、開発者のインフラストラクチャと Kubernetes の構成と管理の複雑さを軽減します。セキュリティ パッチは、実行中のクラスターに自動的に適用されます。
//マニフェスト (別名 YAML)
開発者は、Kubernetes クラスターとのローカル通信を、Kubectl (Kube Control) または REST API の呼び出しという 2 つの方法で実装できます。どちらの方法でも、共通の YAML 構造を使用してペイロードをクラスターに送信します。
これをマニフェストと呼び、次の詳細な手順が含まれています。
何を展開しているのか
どのように展開するか
何を暴露するのか
どうやって暴露するか
以下は、多くのコンテナ アプリケーションに使用できる YAML テンプレートの例です。以下にマニフェストの基本概念を紹介します。
//ラベル/ラベル
Kubernetes 内のすべてのものにはラベルが必要です。ラベルはクラスター内のすべてのリソースを識別する方法であり、Kubernetes に Kubectl コマンドまたは API リクエストを使用して何を探すかを指示する方法です。
//ポッド
ポッドは Kubernetes の最小のオブジェクトであり、コンテナーが存在します。
ポッドには複数のコンテナーを含めることができますが、高度に結合した障害点を避けるために 1 対 1 の関係をお勧めします。ポッドに関して注目すべき重要な機能は次のとおりです。
ポッドは一時的なものです。つまり、内部のコンテナーに障害が発生した場合、最も可能性の高い結果は、Kubernetes がポッドを削除して新しいポッドを作成することです。新しいバージョンのコンテナをデプロイすると、通常は新しいポッドが作成され、Kubernetes がバランシング サービスのバックエンドの更新を処理します。
コンテナイメージを指定する必要があります。リポジトリ名とイメージ名として定義されます。例: [aws アカウント ID].dkr.ecr.[aws リージョン].amazonaws.com/imageName
リソース制限を設定することがベスト プラクティスです。境界には 2 種類あります。
1. リクエスト:これがポッドの保証対象です。30 分以内の配達保証付きでピザを注文するようなものです。これはピザをもっと早く配達できないという意味ではなく、1 人の配達員がどれだけの注文を処理できるかの指標にすぎません。リクエストの場合、クラスター内のコンピューティング リソースの割り当ての保証を指定します。ポッドが 1 つしかない場合は、保証されているよりも多くのコンピューティング リソースを取得できる可能性が高くなります。
2. 制限/制限:これは、ポッドのハード制限です。制限を指定すると、リソースが利用可能であっても、ポッドは指定された制限を超えて消費しません。同じ配達員の例で言えば、いかなる状況であっても同時に 3 枚以上のピザを配達することはできないと言っているようなものです。
Kubernetes で一般的に使用される単位は次のとおりです。
1. Mi で表されるメビバイト/メガバイト (MiB) : メモリの尺度として使用されます。miB から MB に変換するには、miB x 1.049 が必要です。
2. m で示されるミリコア (mc): CPU の測定値として使用されます。1 CPU コアは1000 ミリコアで表されます。たとえば、250m は 1/4 CPU コアです。
//レプリカセット
ポッドは、CPU やメモリ消費量などのさまざまなメトリクスに基づいてレプリケートされている必要があります。レプリカを 1 つだけ設定する場合は、次の例に示すように静的な値を設定することもできます。このレプリカと自動スケーリング ルールのセットを ReplicaSet と呼びます。
開発者が Pod を直接呼び出すことはお勧めしません。前に説明したように、これらは一時的なものであり、ポッド名と IP は動的であることを意味します。
ここでサービスが登場します。同じ ReplicaSet から 1 つ以上の Pod を呼び出すための単一のアクセス ポイントを提供します。次の 2 種類のサービスに焦点を当てます。
LoadBalancer/ロード バランサー:このタイプのサービスは、ReplicaSet を Kubernetes クラスターの外部に公開する必要がある場合に使用されます。プライベート ネットワークにすることも、インターネットに公開することもできます。Amazon EKS に関する限り、注意すべき点が 2 つあります。
1. サービス名は常に文字で始まり、区切り文字として「-」を使用する必要があります。たとえば、picturesocial-pictures;
2. プライベート ロード バランサーの場合: サービス アノテーションが必要です。次の例では、サービスが内部的にのみ公開されることを指定します。
clusterIP:このサービスは、Kubernetes クラスター内でユーザーに ReplicaSet を提供する必要がある場合に使用されます。これは最も一般的なアプローチでもあり、ポッドをクラスター境界内に保持する方が安全です。このようにして、Pod を使用するために、イングレス コントローラー、双方向認証、API ゲートウェイなどのセキュリティ レイヤーを追加できます。これらの概念については、今後の記事で詳しく説明します。
サービスは常にバックエンドの変更を検出するため、ポッドがオフラインになるか、新しいポッドに置き換えられると、サービスはトラフィックの送信を停止し、動作中のポッドに再ルーティングします。このため、API が 1 つのポッドのみで構成されている場合でも、ポッドを直接呼び出すのではなく、同期通信にサービスを使用する必要があることを強調します。
//画像の名前空間
Kubernetes はマルチテナント コンテナ オーケストレーターです。これは、複数のアプリケーションと環境を同時に処理するソリューション向けに設計されていることを意味します。
ここで名前空間が登場します。Namespac は、Kubernetes 内部リソースの論理区切りとして機能し、リソース (Pod、サービスなど) を特定の Namepac にバインドし、特定の権限を設定できます。たとえば、名前空間 A の Pod が名前空間 B の Pod にアクセスできないように設定できます。
ビジネス ドメイン リソースを名前空間にグループ化することをお勧めします。これにより、必要なリソースが見つけやすくなり、チームがソフトウェア プロジェクト内の特定のビジネス ドメインを独立して管理できるようになります。
Kubernetes
ホスティングに適したアプリケーションの種類
いずれにせよ、Kubernetes を使用することは、スーパーマーケットまで F1 カーを運転するようなものです。そうしたいと思っていますが、まだ少し無理があります。Kubernetes をいつ使用するかを選択するときは、次の基準を使用します (もちろん、実際の状況に応じて調整する必要があります)。
私のコンテナ化されたアーキテクチャは、同じインフラ上で独立して実行およびスケーリングする少なくとも 10 の異なるサービスで構成されています。
私のサービスにはローカル ネットワーク環境に存在する依存関係があり、それらの依存関係を呼び出すにはトラフィック ポリシーと認証が必要です。
私はさまざまなチームと協力して、同じアプリケーションのさまざまなコンポーネントを保守および開発しています。
コンピューティング、ネットワーク、ネットワーク ポリシー、ローリング ポリシー、および Orchestrator のバージョン管理を制御する必要があります。
一貫したツールセットと導入戦略を備え、オンプレミスからクラウドまで拡張できるソリューションが必要です。
上記のオプションのうち 2 つ以上が満たされる場合は、Kubernetes が適切な選択となります。
この記事は一般的な科学記事として情報量がやや多く、コンテナを初めて使用する開発者にとっては理解するのに時間がかかるかもしれませんが、コンテナを始めたばかりの開発者がコンテナの動作原理を理解するのに役立つことを期待しています。を編集し、いくつかの特別な用語に精通しておいてください。フォローアップの Picturesocial シリーズ記事では、特定のケースのデモンストレーションを通じて、これらの概念がどのように適用されるかを示します。
後の記事では、Terraform を使用して実際に Amazon EKS クラスターを作成する方法を一緒に学びます。
楽しく働いて頑張って生きてくださいね〜
開発者向けのテクノロジー共有やクラウド開発トレンドについて詳しく知るために、「Amazon Cloud Developer」 WeChat 公式アカウントに引き続きご注目ください。
聞いたので、下の 4 つのボタンをクリックしてください
バグに遭遇することはありません！
