ハイライト
- Kubernetes アーキテクチャは、コントロールプレーン/ワーカーノードモデルをベースとしています。
- Kubernetes クラスタは、安全で使いやすく、拡張可能であるべきです。
- クラスタにはコントロールプレーンとノードという 2 つの部分があります。コントロールプレーンは全体的な意思決定を行い、ノードはアプリケーションを実行します。
- 素のままの Kubernetes には、異なるノード上の Pod が相互に通信する手段、内部にインターネット・トラフィックをルーティングする方法、ログを簡単に表示する方法が含まれていません。
- Kubernetes はコンテナ化された大規模で複雑なアプリケーションをオーケストレーションするためのツールを提供しますが、多くの決定はユーザーに委ねられています。
Kubernetes アーキテクチャとは
Kubernetes アーキテクチャは、コントロールプレーン/ワーカーノードモデルをベースとしています。このアーキテクチャではクラスタを 2 つの主要レイヤーに分割します。1 つはコントロールプレーンであり、これはグローバルな意思決定を行い、クラスタを管理します。もう 1 つはワーカーノードで、これはコンテナ内でアプリケーションを物理的に実行します。
Kubernetes の基礎を学んだばかりという方は、Kubernetes が分散アプリケーションおよびサービスを大規模に実行するために設計されたオープンソースのコンテナ・オーケストレーション・プラットフォームであるという知識はお持ちでも、Kubernetes のコンポーネントと、それらがどのように相互作用するかについてはまだご存じないかもしれません。
ここではまず Kubernetes の基盤となる設計原則を簡単に確認し、次に Kubernetes のさまざまなコンポーネントがどのように連携するかを見ていきます。
Kubernetes の設計原則とは
Kubernetes クラスタの設計は、Kubernetes 実装の詳細で説明されている 3 つの原則に基づいています。
Kubernetes クラスタは次のようなものであるべきです。
- 安全であること。セキュリティに関する最新のベストプラクティスに従う必要があります。
- 使いやすいこと。わずかな数の簡単なコマンドで操作できる必要があります。
- 拡張可能であること。特定のプロバイダーを優先することはしません。また、設定ファイルからカスタマイズできる必要があります。
Red Hat Advanced Cluster Management for Kubernetes
Kubernetes コントロールプレーンの機能
Kubernetes コントロールプレーンはクラスタの「頭脳」です。グローバルな意思決定 (アプリケーションのスケジューリングなど) を行い、クラスタイベントを検出してそれに対応し、クラスタの実際の状態を、宣言された望ましい状態に一致させます。
Kubernetes コントロールプレーン内には、クラスタを制御するコンポーネントと、クラスタの状態と構成に関するデータがあります。これらの Kubernetes コアコンポーネントは、十分な数のコンテナが実行され、必要なリソースが割り当てられていることを確認するという重要な作業を担います。
コントロールプレーンはコンピュートマシンと常に通信しています。クラスタを特定の方法で実行するように設定すると、コントロールプレーンが確実にその通りに実行します。
kube-apiserver
Kubernetes API は Kubernetes コントロールプレーンのフロントエンドであり、内部からの要求と外部からの要求を処理します。API サーバーは要求が有効かどうかを判断し、有効な場合は処理します。API へは、REST 呼び出し、kubectl コマンドラインインタフェース、または kubeadm などの他のコマンドラインツールを使用してアクセスできます。
kube-scheduler
スケジューラーは、クラスタの健全性とともに、Pod のリソースニーズ (CPU やメモリーなど) を考慮します。そして、Pod を適切なコンピュートノードにスケジュールします。
kube-controller-manager
コントローラーは実際のクラスタの実行を処理します。Kubernetes コントローラー・マネージャー 1 つで、いくつかのコントローラー機能を実行します。あるコントローラーはスケジューラーに問い合わせて、正しい数の Pod が稼働していることを確認します。Pod がダウンした場合、別のコントローラーが検知して対処します。さらに別のコントローラーはサービスを Pod に接続します。これにより、リクエストが正しいエンドポイントに送られます。他にも、アカウントと API アクセストークンを作成するためのコントローラーなどがあります。
etcd
構成データとクラスタの状態に関する情報は、key-value ストアデータベースである etcd 内にあります。etcd は、フォールトトレラントで分散されており、クラスタに関する信頼できる基本的な情報源となるように設計されています。
Kubernetes ノードの機能
コントロールプレーンが頭脳であれば Kubernetes ワーカーノードは筋肉であり、アプリケーションを実行するという実際の処理を担当します。
Kubernetes ノードは、物理マシンの場合も仮想マシン (VM) の場合もあります。ノード内では、コントロールプレーンからの命令の受信、コンテナの実行、ネットワークの管理、正常性ステータスの報告という、継続的なサイクルが行われています。
Kubernetes クラスタは少なくとも 1 つのコンピュートノードを必要としますが、通常は多数を有しています。Pod はスケジュールおよびオーケストレーションされてノード上で実行されます。クラスタの容量をスケールアップする必要がある場合は、ノードをさらに追加します。
Pod
Pod はKubernetes オブジェクトモデルの最も小さくて単純な単位であり、アプリケーションの単一のインスタンスです。各 Pod は、1 つのコンテナまたは密結合された複数のコンテナと、コンテナの実行方法を制御するオプションで構成されます。Pod を永続ストレージに接続すれば、ステートフル・アプリケーションを実行できます。
コンテナ・ランタイム・エンジン
コンテナを実行するために、各コンピュートノードにはコンテナ・ランタイム・エンジンがあります。Docker は 1 つの例ですが、Kubernetes は rkt や CRI-O などの他の Open Container Initiative 準拠のランタイムもサポートしています。
kubelet
各コンピュートノードには、コントロールプレーンと通信する小さなアプリケーションである kubelet が含まれています。kubelet は、コンテナが確実に Pod 内で実行されるようにします。コントロールプレーンが、ノードでの何らかの処理を必要とする場合、kubelet がアクションを実行します。
kube-proxy
各コンピュートノードには、Kubernetes ネットワークサービスを円滑に実行するためのネットワークプロキシである kube-proxy も含まれています。kube-proxy は、オペレーティングシステムのパケットフィルタリング・レイヤーを使用するか、自らがトラフィックを転送して、クラスタ内外のネットワーク通信を処理します。
Kubernetes クラスタに必要なその他の要素
技術的には、Kubernetes クラスタはコントロールプレーンとワーカーノードさえあれば完成します。ただし、これだと完全にコアな部分のみです。実は、素のままの Kubernetes には、異なるノード上の Pod が相互に通信する手段、内部にインターネット・トラフィックをルーティングする方法、ログを簡単に表示する方法が含まれていません。
クラスタをプロダクション環境で使用できるようにするには、アドオンとサポートするインフラストラクチャをインストールする必要があります。
- ネットワーク：Kubernetes の Pod が異なるノード間でシームレスに通信できるようにするためには、仮想ネットワーク・オーバーレイが必要です。このネットワークレイヤーを作成してすべての Pod に一意の IP アドレスを割り当てるには、Cilium や Calico などの Container Network Interface (CNI) プラグインをインストールする必要があります。
- Ingress コントローラー：内部トラフィックは自動的に処理されますが、外部からのトラフィックを受け入れるにはゲートウェイが必要です。NGINX や Traefik などの Ingress コントローラーは、リバースプロキシおよびロードバランサーとして機能し、外部インターネット・トラフィックをクラスタ内の適切なサービスに安全にルーティングします。
- クラスタ DNS：Pod の IP アドレスは再起動によって常に変更されるため、ネットワークパスをハードコーディングすることはできません。クラスタ DNS プロバイダー (通常は CoreDNS) は永続ドメイン名をサービスに自動的にマッピングし、アプリケーションが常に互いを特定できるようにします。
- ストレージプロビジョナー：コンテナは本質的にステートレスなので、クラッシュした場合、保持されていたデータはすべてなくなります。Container Storage Interface (CSI) は、クラスタを外部の物理ストレージ (クラウドディスクや NFS) にリンクさせ、自動的に永続的なハードドライブをプロビジョニングして接続することで、データが再起動後も維持されるようにします。
- 可観測性スタック：アプリケーションは複数のマシンに分散しているため、トラブルシューティングには一元化されたインサイトが必要です。Prometheus や Grafana などのツールは、FluentBit などのロギングエージェントとともに、コンテナのログを検索可能な単一のダッシュボードに集約し、クラスタのメトリクスを監視します。
Kubernetes アーキテクチャの課題
この記事は Kubernetes アーキテクチャの基本に関する概説であり、説明しているのは全体のほんの一部でしかありません。それらのコンポーネントが相互に、また外部のリソースやインフラストラクチャとどのように通信するかを考えてみれば、Kubernetes クラスタの設定とセキュリティ保護がいかに難しい課題であるかはご想像いただけるでしょう。
Kubernetes はコンテナ化された大規模で複雑なアプリケーションをオーケストレーションするためのツールを提供しますが、多くの決定はユーザーに委ねられています。オペレーティングシステム、コンテナランタイム、継続的インテグレーション/継続的デリバリー (CI/CD) ツール、アプリケーションサービス、ストレージ、その他のほとんどのコンポーネントはユーザーが選択します。それに加えて、ロール、アクセス制御、マルチテナンシー、セキュアなデフォルト設定を管理する作業もあります。さらに、Kubernetes を独自に運用するか、サポート付きバージョンを提供できるベンダーと連携するかを選ぶこともできます。
このように選択できる自由度は、Kubernetes の柔軟な性質によるものです。実装が複雑な作業になる可能性はありますが、Kubernetes はコンテナ化されたアプリケーションを独自の条件で実行し、組織の変化に俊敏に対応できるようにするための大きな力を提供します。
Kubernetes でクラウドネイティブ・アプリケーションを構築する
こちらの Web セミナーシリーズでは、アプリケーションの構築、実行、デプロイ、モダナイズに必要なデータプラットフォームをエンタープライズ Kubernetes 上に確立する方法について、エキスパートの視点をご確認いただけます。
Kubernetes に Red Hat OpenShift を選ぶ理由
Red Hat は、Kubernetes を含むオープンソース・コンテナ・テクノロジーのリーダー企業であるとともに積極的に開発も行っており、コンテナ・インフラストラクチャの保護、単純化、自動更新に不可欠なツールを生み出しています。
Red Hat® OpenShift® はエンタープライズグレードの Kubernetes ディストリビューションです。Red Hat OpenShift により、チームは DevOps のための単一の統合プラットフォームを得ることができます。Red Hat OpenShift では、開発者が言語、フレームワーク、ミドルウェア、データベースを選択でき、さらに CI/CD を介して自動化を構築およびデプロイして生産性を大幅に向上させることができます。また、コンテナ用に設計されたデータおよびストレージ・サービス・プラットフォームである Red Hat OpenShift Data Foundation もあります。
