Kubernetesアーキテクチャの概要と設計方法の基本を解説

Kubernetesは、コンテナ化されたアプリケーションを導入、スケール、管理するためのプラットフォームです。

ひと通りの機能は最初から備わっていますが、初期状態のままでは、セキュリティやスケーラビリティの問題が発生したり、運用が複雑になったりする可能性があります。

そこで重要となるのがKubernetesアーキテクチャの設計戦略です。環境に合わせて適切に設計することで、クラスターの管理やアプリケーション実行などを効率よく効果的に行いやすくなるほか、安全面でのリスクを低減できます。

この記事では、Kubernetesアーキテクチャの概要を紹介したうえで、設計方法の基本を解説します。

関 連 記 事

Kubernetesとは？Kubernetesセキュリティ
の基礎Kubernetesアーキテクチャの
設計方法AWSのEKS
（Elastic Kubernetes Service）Kubernetesの
クラスターとは？ Kubernetes のノードとは？KubernetesのPodとは？KubernetesのHelmとは？クラウドセキュリティと
ランタイムインサイト

Kubernetes アーキテクチャの概要

アーキテクチャとは、システムの基本構造や骨組みのことです。Kubernetesアーキテクチャは、主にコントロールプレーンとノードで構成されており、その中にさまざまなコンポーネントが含まれます。

関連ページ：Kubernetesとは?　基本をわかりやすく解説

コントロールプレーンは、Kubernetesクラスターの中枢です。クラスターを制御するためのコンポーネント、クラスターの構成や状態に関するデータなどで成り立っています。

ノード（Node）は、ポッド（Pod）をホストし、コンテ場が実際に動作する物理的なマシン、もしくは仮想的なマシンのことです。

Kubernetes アーキテクチャ設計が重要な理由

Kubernetes環境の形状やコンポーネントはそれぞれ異なり、どのように何を配置するかで安全性や可用性が大きく変わることから、アーキテクチャ設計段階で戦略を立てることが重要です。

もしアーキテクチャの設計が不適切な場合、例えば以下の問題が起きる可能性があります。

• スケーラビリティでトラブルが起きる：クラスターのスケーリングの際にリソースの不足やボトルネックが発生する。
• セキュリティリスクが高まる：セキュリティ上の脆弱性が生まれ、不適切なアクセス制御、認証の問題、ネットワークの脆弱性などが起きる。
• 可用性が低下する：マスターコンポーネントの単一障害点により、クラスター全体がダウンする。
• パフォーマンスが低下する：リソースの割り当て、ネットワーク、コンポーネント間の通信などの効率が悪くなり、クラスターのパフォーマンスが下がる。
• 運用が複雑になる：設計の仕様でスケーリングが制限されたり、問題の特定や解決が難しくなったりしたことにより、運用が複雑になり、混乱を招きやすくなる。

アーキテクチャを適切に設計することで、問題の迅速な特定や解決、セキュリティリスクの低減、リソース利用の最適化、高可用性の維持が可能となります。安全に効率よくKubernetesを運用するには、戦略的に設計を進めることが大切です。

Kubernetes アーキテクチャ設計に必要な知識

Kubernetesのアーキテクチャを設計するには、さまざまな知識を身につける必要があります。例えば、以下のような知識が役立つはずです。

• クラウドやコンテナに関する知識：クラウドやコンテナの基本、Dockerをはじめコンテナランタイムの基本的な概念や操作方法。
• Kubernetesの基本概念：クラスター、ノード、ポッド、サービス、レプリカセットなどの基本的なKubernetesの用語と概念。
• アプリケーションアーキテクチャの知識：アプリケーションのデプロイメント、スケーリング、管理を行うためのアーキテクチャについての知識。
• ネットワーキングとセキュリティの知識：Service、Ingress、ネットワークポリシーなどの概念を含む、ネットワーキングとセキュリティについての知識。
• スケーリングの知識：スケーラビリティと可用性の確保などに必要な、クラスターのスケーリングについての知識。
• ツールの知識：エコシステムに含まれるHelm、Prometheus、Istioなどのツールについての知識。

Kubernetesはクラウド環境におけるコンテナオーケストレーションプラットフォームのため、運用するにはクラウドやコンテナ、セキュリティ、ITインフラ設計など幅広い知識が求められます。

なお、クラウド環境は、従来のオンプレミス環境よりも複雑になりがちです。環境によって構造も異なるため、ただ知識を学んだだけでは諸問題の解決が難しい場合もあります。実際に操作しながらクラスターの構築、デプロイメントやトラブルシューティングなどの実践的な経験を積むことで、身につけた知識を活用しやすいです。

Kubernetes アーキテクチャの設計方法

Kubernetesアーキテクチャを設計するには、様々な選択肢の中から最善なものを選びながら進める必要があります。また、正解はひとつではなく、目指す環境の方向性にあわせて変わるはずです。

ここでは、安全なセキュリティ実現を目指すことを想定し、Kubernetesアーキテクチャの設計方法を解説します。

採用するKubernetesの選択

Kubernetesの選択肢は、プロバイダが提供するマネージドサービスと、自社のインフラストラクチャでの自前構築の主に2種類です。

マネージド Kubernetes サービスは、Amazon EKS や Azure Kubernetes Service などで使われるツールです。クラスターの稼働を維持するために必要なプロビジョニングタスクとメンテナンスタスクの少なくとも一部を Kubernetes プロバイダが担うため、多くの場合はセットアップとメンテナンスが容易です。

専門家が管理し、セキュリティ脅威を監視していることから、基本的な安全性は確保されています。セキュリティの観点から見て、ベストプラクティスに準拠している事前構成済みの設定やツールを利用できる傾向です。

ただしセキュリティ上の欠点もあります。ベンダーが所有するツールとインフラストラクチャを使用することが多いため、ユーザーの操作やプライバシーが制限されがちです。特定のマネージド Kubernetes プラットフォーム（Platform9など）はオンプレミスのインフラストラクチャと互換性があるものの、大半はパブリッククラウドでホストされているインフラストラクチャを使用しなければなりません。

対して、自社のインフラストラクチャに自前で構築・運用する場合、ニーズにあわせて自由にカスタマイズできるほか、制御も自在です。安全面での制限もなく、データのセキュリティやプライバシーの管理も総合的に行えます。マネージドサービスのように他社へ利用料を払う必要もないため、コストを削減できる可能性もあるでしょう。

しかし自社で全てを行うため、運用にはリソースが必要で複雑になりがちです。定期的なバージョンアップへの対応や更新作業も必要となります。そもそも各種専門知識やノウハウ・経験がなければ、適切な構築や運用もできず、大きなリスクを抱えることになります。

結論としては、導入が初めてで、Kubernetes のセキュリティ原則に精通していないなら、マネージドKubernetesサービスを選ぶのがおすすめです。自分でセットアップするよりも安全な環境を確保しやすくなります。ただし、高度なセキュリティ構成は、アーキテクチャを自前構築しなければ実現できません。

実現したい環境をイメージし、最適なものを選びましょう。

クラスター数の選択

Kubernetesを導入するなら、セットアップするクラスターの数も決定する必要があります。

従来は単一のクラスター（クラスター数が1つ）が採用されるのが一般的でしたが、現在はマルチクラスター環境（クラスター数が複数）が選ばれるケースが増えています。

最大の理由は、マルチクラスターならワークロード間を高度に分離できる点です。あるワークロードで問題が起きたとしても、他のワークロードが別のクラスターに配置されていれば、影響を最小限にとどめることができます。これはセキュリティの観点からも非常に有効です。

関連ページ：Kubernetesクラスターのセキュリティ、コンポーネント別

ただし、クラスターの数が増えれば、そのぶん構築や運用は複雑になる傾向が見られます。クラスターが多くなれば、構成と分離が求められるネットワーク、追跡しなければならない監査ログも増加するため、手間やコストもかかるでしょう。とはいえ、クラスター監視や管理をツールで自動化できているなら、そこまでデメリットにはならないため、マルチクラスターのアーキテクチャを選ぶほうがよいケースが大半です。

監視が自動化されていないケース、複雑なクラスター構成を避けたいケースなら、クラスター数は1つにしましょう。シングルクラスターなら、運用に関わる作業が単純になるため、難易度が大幅に下がる傾向にあります。

namespaceの選択

namespaceは、同じ物理クラスター内でホストされる仮想クラスターのことをさします。クラスター数が少なくとも、namespaceの数を適切に増やすことによって、非常に強力な形でワークロードを分離することが可能です。

通常は、Kubernetesで実行するアプリケーションごとに異なるnamespaceを作成します。また、開発/テストと実稼働用にも異なるnamespaceを作成した方がよいでしょう。

ただし、namespaceの数は無限に増やせるわけではありません。ClusterRole で割り当てた権限は、すべてのnamespaceに適用されます。よって、複数のnamespaceが役に立つのは、各namespace内でユーザーとアカウントを分離できる RBAC ポリシーを作る場合のみです。これを実現するには、できる限りClusterRoleではなくRoleを使って権限を割り当てます。

サービスメッシュの配置

サービスメッシュは、アプリケーションレベルの通信をインフラストラクチャ側で制御できるようにするツールです。

採用により、アプリケーション自身での制御が不要になります。クラスター内で稼働しているリソースのサービス検索と接続を管理するものは、ある程度のサービスが含まれている環境にとって欠かせません。

特にKubernetesのセキュリティ面で、サービスメッシュが有効に働きやすいです。接続の管理に役立つだけでなく、セキュリティ脅威の検出に役立つ監視機能とアラート機能も提供するものも多くあります。

ただしデメリットとして、Kubernetesの攻撃対象を全体的に拡大することが挙げられます。サービスメッシュへ侵入されると、そこを経由してクラスター全てに侵入される可能性があるでしょう。とはいえ安全に構築できていれば、攻撃の拡大を防ぐことができるため、設計時の戦略で考えることをおすすめします。

セキュリティソフトウェアと外部監視の選択

クラスターの管理に、サービスメッシュとあわせて、サードパーティのパフォーマンスやセキュリティ監視ソフトウェアなどの外部監視を利用する事例も多いです。これらのツールは攻撃対象を増やすことにはなるものの、活用次第では心強い味方となります。

外部ツールを安全に導入するなら、各エージェントには必要な権限だけを割り当てるのもポイントです。データをストリーミングする際も、できるだけWebhookなどを利用しましょう。クラスター外でツールを使うため、クラスター内で分離するよりもセキュリティ面のリスクを下げることができます。

さらに、外部ツールに保存されるデータを確実に保護し管理することで、悪用される可能性を減らせるはずです。

関連ページ：最も安全なKubernetesアーキテクチャーをデザインする方法

まとめ

効率よく安全にKubernetesを構築・運用するなら、アーキテクチャの設計を戦略的に行う必要があります。設計に単一の正解はありません。一般的なアーキテクチャの設計には、様々な要素が影響し、それは環境やニーズによって異なります。

環境が小規模なら、デフォルトのシンプルな状態で運用するのが正解となるかもしれません。ですが大規模で複雑な環境の場合、多くのコンポーネントを含むマルチクラスターでなければ、求める結果を出すのは難しくなります。

まずは状況を正確に把握し、最適なアーキテクチャの条件を絞り込むことが重要です。