Definition
Kubernetes は、コンテナーのワークロードを調整および管理するために使用されるプラットフォームです (例: Dockerコンテナ)。
2014 年の最初のリリース以来、Kubernetes (ルーツは Google の開発チームに遡るオープンソースの CNCF 卒業プロジェクト) は、DevOps およびクラウド ネイティブ サークルで最も人気のあるツールの 1 つになりました。
Kubernetes を理解するための前提条件は、まずコンテナーについて理解することです。 一言で言えば、コンテナーは、アプリケーションの実行に必要なすべての依存関係を含む軽量のソフトウェア パッケージです。 コンテナーは、さまざまな環境でアプリケーションを確実に実行するという問題を解決します。 コンテナは軽量でポータブルであるため、人気が急上昇しており、最新のマイクロサービスや Web アプリケーションの開発に不可欠です。
単一コンテナーの使用には多くの管理やオーケストレーションは必要ありませんが、大規模なアプリケーションは拡張できる必要があります。 最新の開発チームは、コンテナーのデプロイメントのプロセスを自動化および拡張できる必要があります。 ここで、Kubernetes などのコンテナ化されたワークロード管理ツールが登場します。 Kubernetes は、不足している管理とオーケストレーションを提供します。
Kubernetes について議論するとき、「管理とオーケストレーション」というフレーズが頻繁に飛び交います。 しかし、それでは具体的なことはあまりわかりません。 簡単に言えば、Kubernetes により、負荷分散、構成管理、ストレージ リソースの構成、自動リソース割り当て (例: コンテナーごとの CPU と RAM)、コンテナーのデプロイメントのスケールアップまたはスケールダウン。
Kubernetes vs Docker
Docker と Kubernetes のトピックに関しては、多くの混乱が生じる可能性があります。 しかし、実際には非常に簡単です。
- Dockerは、コンテナを作成および実行するためのプラットフォームです。 コンテナプラットフォームはこれだけではありませんが、最も人気があります。
- Kubernetes は、Docker コンテナを含む複数のコンテナを管理するためのツールです。
- Docker は、Swarm として知られる Kubernetes と同じ機能のいくつかを備えたツールを提供します。
この最後の点が、混乱を招きかねないものです。 Docker はたまたま、Kubernetes と同様の機能を提供するツール Swarm を提供しています。 ただし、管理およびオーケストレーション ツールとしては Kubernetes の方がはるかに人気があります。
Kubernetes の重要な概念と用語
Kubernetes を使い始める際には、コンテナー以外にも理解すべき重要な概念があります。 いくつかの重要な用語を見てみましょう。
- K8sです。 これは Kubernetes の同義語です。 開発者は、単語の最初と最後の文字、その間の文字数を取得し、それを単語の短縮形に組み合わせることで、一般的な用語の短縮形を作成することがあります。 相互運用性は「i14y」、ローカリゼーションは「l10n」、Kubernetesは「k8s」になります。
- ポッド。これらは、Kubernetes にデプロイできる最小単位です。 ポッドは、ストレージとネットワークリソースを共有する 1 つ以上のコンテナと、コンテナを実行するための仕様で構成されます。
- ワークロード。 これらは、Kubernetes が実行するアプリケーション (実際にはポッドのセット) です。 Kubernetes は更新をデプロイし、構成されたワークロードの指示に基づいてポッドをスケーリングします。
- ノード。 ワークロードが実行されるコンピューティング「ハードウェア」 (RAM や CPU など) はノードと呼ばれます。 「ハードウェア」には、Raspberry Pi から仮想マシン、物理サーバーまで何でもあります。ここで重要なのは、コンピューティング リソースがノードから供給されるということです。 ノードには、ワークロードを実行するワーカー/ミニオン ノードと、一連のワーカー/ミニオン ノードを管理するマスター ノードの 2 種類があります。
- クラスター。 Kubernetes クラスターはノードのグループです。 クラスタでは、ワーカー・ノードがワークロードを実行し、マスター・ノードがワーカー・ノードの動作を制御します。
Kubernetes は何に使用されますか?
Kubernetes は、コンテナのデプロイメントに対するコードとしてのインフラストラクチャのアプローチが役立つあらゆる場所で効果的に役立ちます。 これは、アジャイル開発チームや DevOps プラクティスに重点を置くチームが、継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインの自動化を支援するために Kubernetes を使用することが多いことを意味します。 さらに、Kubernetes は、ノードの健全性とリソース使用率を監視し、必要に応じてスケールアップまたはスケールダウンすることで、クラウド ネイティブ アプリケーションの自動スケールを支援します。
Kubernetes セキュリティの重要な概念
もちろん、Kubernetes は自動化とスケーラビリティの観点から価値を追加しますが、セキュリティ チームにとっては新たな問題も生じます。 アプリやサービスを安全にデプロイするにはどうすればよいでしょうか。 いつものように、これは脅威モデルとリスク選好度を理解することから始まりますが、始めるのに役立ついくつかの基本があります。
- クラウド ネイティブ セキュリティの 4C – Kubernetes は、4C として知られるクラウドネイティブセキュリティへの 4 層のアプローチを呼び出します。コード、コンテナ、 C光沢、ラウド/拠点/企業データセンターです。 各レイヤーでは、セキュリティのベストプラクティスに従っていることを確認する必要があります。 これは、レベルによって意味が異なります。 たとえば、コードにより転送中のデータの暗号化が強制され、アクセスが重要なネットワーク ポートのみに制限されること、コンテナ内の特権ユーザーの禁止、構成可能な Kubernetes クラスター コンポーネントの強化、クラウド サービス プロバイダーのセキュリティのベスト プラクティスに従うことを保証します。
- ポッドのセキュリティポリシー。 Kubernetes ポッドには、3 つの基本セキュリティ ポリシーがあります。 環境を適切にセキュリティで保護するには、それぞれのユーザビリティとセキュリティのトレードオフを理解し、それに応じて行動する必要があります。
- 特権。最も広範なレベルのアクセス許可。 既知の特権エスカレーションは、このポリシーで可能です。
-
- ベースライン/デフォルト。 特権と制限の中間です。 既知の特権エスカレーションを防止します。
- 制限付き。 Kubernetes ポッド強化のベスト プラクティスに基づいており、これは 3 つの基本ポリシーの中で最も制限的なものです。
- ポッドのセキュリティー・コンテキスト。 ポッドのセキュリティコンテキストは、実行時にセキュリティ設定を構成します。 これには、アクセス制御、特権としての実行かどうか、読み取り専用ファイルシステムのマウントなどの側面が含まれます。 これはPodのセキュリティポリシーによく似ていると思われるかもしれませんが、実際、それらは関連しています。 セキュリティー・コンテキストは実行時に発生するものですが、セキュリティー・ポリシーでは、クラスター内で使用するコンテキストのパラメーターを定義できます。
- 秘密。Infrastructure-as-Codeツールは素晴らしいツールですが、OAuthトークンやパスワードをYAMLファイルに入れたくないでしょう。 シークレットは、この種の機密情報を保存する Kubernetes の方法です。
また、コンテナの可視性と脆弱性のスキャンを計画し、問題を迅速に修復し、関連する標準への準拠を維持することも重要です。 コンテナの脆弱性スキャンとセキュリティ体制の評価を開始するには、 「Continuous Container Visibility and Conpriians (PDF)」を読むことをお勧めします。
Feedback