Kubernetes と AKS の概要

完了

あなたは、Contoso のコンピューティング環境におけるワークロードの機敏性と密度を向上させるためにコンテナー化の原理について調べていたときに、個々のコンテナーのデプロイではなく、コンテナー オーケストレーションに焦点を当てる必要があることに気付きます。 後者の方が容易ですが、スケーラビリティと回復性が欠けています。 コンテナー オーケストレーションの調査では、短時間のうちに、Kubernetes と AKS が、計画した実装に最適な候補であることを特定しました。

Kubernetes とは

Kubernetes は、コンテナー化されたワークロードを調整するための、拡張可能な Linux ベースのオープンソース プラットフォームです。 回復性を確保するため、典型的な Kubernetes デプロイは、ノードと呼ばれる、複数のクラスター化されたサーバーで構成されます。 これらの一部は、ワークロードのデプロイ先となる残りのノードの管理を担うコントロール プレーンを形成します。 Kubernetes の場合、これらのワークロードは、ポッドと呼ばれるコンテナー化されたアプリケーションのインスタンスで構成されます。

Note

コントロール プレーンのコア コンポーネントの 1 つは API サーバーで、これには、Kubernetes クラスターの構成と管理のためのインターフェイスが用意されています。

Note

ポッドはコンテナーにほぼ対応しますが、同じクラスター ノードで実行されている、複数の密接に結合されたコンテナーを含むことができます。

ポッドは通常、ステートレスであり、固有の回復性機能は備わっていません。 高可用性と冗長性を実装するため、デプロイを使用してそれらをプロビジョニングすることができます。 通常、デプロイは、同じ構成を共有していて、同じイメージに基づくコンテナーを実行している、複数のレプリカのポッドで構成されます。 Kubernetes では、デプロイ内のポッドのライフサイクルを自動的に管理し、使用可能なクラスター ノード全体にわたり、障害が発生したものはすべて最適な方法で再作成します。

デプロイを使用すると、コンテナー化されたワークロードの可用性に影響を与えることなく、ポッド内で実行されているコンテナーのイメージの更新も効率化されます。 中断の予算を定義することで、更新プロセス全体を通してオンラインのままにする必要があるポッド レプリカの数を制御します。

ポッドへの直接接続については、サービスと呼ばれる別の種類の Kubernetes リソースを実装できます。 たとえば、サービスを使用すると、インターネットから同じデプロイの一部としてのポッドのグループでホストされている Web サービスに向かうように、負荷分散される外部接続を設定できます。

Kubernetes には、ポッド、サービス、デプロイ、およびその他多くのクラスター コンポーネントを名前空間に分離する機能が用意されています。 名前空間によって論理的な境界が形成され、これを使用して、クラスター リソースを作成、表示、または使用するためのアクセスを制限することができます。

Kubernetes の主な利点

Kubernetes には、共有されるコンピューティング、ネットワーク、ストレージのリソースを使用するマルチコンテナー環境に向けた一貫性のある管理モデルが用意されています。 宣言型のデプロイと管理のモデルが提供されており、ユーザーが望ましい構成を記述すると、その実装は Kubernetes のコントロール プレーンに任されます。

Note

宣言型の管理モデルの導入により、YAML 形式のマニフェスト ファイルを使用して、ポッド、サービス、デプロイなどの Kubernetes コンポーネントをプロビジョニング、変更、削除します。 Helm チャートと呼ばれる、パッケージ化された YAML ファイルのコレクションを使用することもできます。 Helm は Kubernetes 用のパッケージ マネージャーで、より複雑なワークロードの、Kubernetes クラスターへのデプロイが容易になります。

また、Kubernetes には以下のような利点があります。

  • ポッドの自己復旧
  • ポッドの自動スケーリング
  • 仮想化されるシナリオでの自動クラスター ノードの自動スケーリング
  • ポッド デプロイの自動ローリング アップデートおよびロールバック
  • ポッドの新しいデプロイの自動検出
  • 同じワークロードを実行しているポッド間での負荷分散

Kubernetes を使用すると、物理サーバーや仮想サーバーのグループを統合されたコンピューティング リソースとして扱うのと同時に、コンテナー化されたワークロードの機敏性と密度を利用してサーバーを最適化することができます。 Kubernetes によってコンテナー管理が簡略化されますが、その管理では、多くの構成、管理、メンテナンスのタスクが必要とされます。

  • デプロイ、スケーリング、負荷分散、ログ記録、監視などの側面はすべてオプションです。 特定のニーズに対処する最適な構成を特定して実装することは、ユーザー側で行う必要があります。
  • ミドルウェア、データ処理フレームワーク、データベースは、Kubernetes ではネイティブで提供されていません。 ただし、コンテナーを使用することにより、対応する任意の機能を実装することができます。
  • 自身の Kubernetes 環境は自分で維持する必要があります。 たとえば、オペレーティング システムのアップグレードと Kubernetes のアップグレードを管理する必要があります。 また、ネットワーク、メモリ、ストレージなど、クラスターノードで使用できるハードウェア リソースの管理も行います。

Note

AKS などのマネージド Kubernetes オファリングでは、これらの課題の一部が最小限になり、解消されることさえあります。

知識チェック

1.

Contoso の Azure Stack HCI 環境にデプロイする予定のコンテナー化されたワークロードについて、Kubernetes 使用の適合性を評価しているうちに、同じ Kubernetes クラスターを使用するユーザーが、コンテナー化されたリソースを作成、表示、または使用するのを制限する必要があることに気付きました。 ユーザーを制限するために、どの Kubernetes 機能を使用する必要がありますか?