Kubernetes の管理について知っておくべき 7 つのこと

「ますます多くのチームが、コンテナ化されたワークロードとアプリケーションを本番環境で実行するために Kubernetes を使い始めています」と、コンテナ ストレージ ベンダー Portworx の CTO 兼共同創設者である Gou Rao 氏は述べています。 「Kubernetes は、ゼロダウンタイムとセキュリティが重要な場合に、大規模で複雑なアプリケーションを本番環境で実行する最も簡単な方法に急速に変わりました。Kubernetes は複雑で、すべての人に適しているわけではありませんが、複数のクラウド プラットフォームやデータ センターで実行する必要がある大規模で複雑なアプリケーションの場合、Kubernetes は手の届かないものではありません。」

[[327810]]

しかし、Kubernetes は、その自動化機能がどれほど強力であっても、万能のツールではありません。多くの企業が実践している管理業務は注目に値します。

「他のプラットフォームと同様に、Kubernetes も管理と保守が必要です」と Harness の DevOps エバンジェリスト、Ravi Lachhman 氏は述べています。

一方、Red Hat のセキュリティ戦略担当である Kirsten Newcomer 氏は、「セキュリティは、できるだけ早い段階で企業のプロセスに組み込む必要があります。新しいテクノロジーは、既存のセキュリティ アプローチに挑戦する可能性があります。たとえば、データ収集やネットワーク セキュリティ ソリューションは、アプリケーションが実行される環境に適応する必要があります。ベスト プラクティスは、実行中のコンテナにパッチを適用しないことです。パッチを適用すると、次にそのコンテナ インスタンスをイメージからデプロイするときに、パッチが失われます。つまり、企業は DevOps とセキュリティへの投資を再評価する必要があります。」と述べています。

Kubernetes を長期管理するための 7 つのヒント

業界の専門家は、エンタープライズ チームと実務者に Kubernetes を管理するための 7 つの提案を提供できます。

1. 企業はKubernetesを重要な投資と見なす必要がある

企業がラップトップやサンドボックス環境で Kubernetes を変更することは 1 つの方法です (多くのチームがこの方法で開始し、Minikube や同様のツールを使用すると比較的簡単に行えます)。しかし、それを本番環境で実行することは別の方法です。

「Kubernetesを適切に導入するには、企業が真剣に取り組む必要がある」とラオ氏は語った。 「実際、すべてのトリックは本質的にそこから生まれます。」彼は、これは強力なソフトウェア エンジンなので、真剣に受け止める必要があると考えています。

「このエンジンは、ユーザーが指定したパラメータに基づいて、いつでもどこでもアプリケーションを実行、移動、再移動できるようにすることを目指しています」とラオ氏は語った。 「Kubernetes が何を実行し、どのように実行するかを理解する必要があります。この運用効率のメリットを享受するには、Kubernetes が効果的に実行される環境を用意する必要があります。」

つまり、企業は適切な人材、インフラストラクチャ、プロセス、文化を備える必要があるということです。多くの企業は、Kubernetes が環境の管理を混乱させる既存の構造上の問題を解決できることを期待しています。

2. コーディネーターにも管理とメンテナンスが必要

一部のチーム（特に始めたばかりのチーム）は、Kubernetes が自動的に実行されると考えるかもしれません。オーケストレーターの宣言的な性質と自動化の重視を考慮すると、これには実際に何らかの疑似ベンチマークがあります。しかし、Kubernetes は他のシステムと同様に、ある程度の管理とメンテナンスが必要です。

「ビジネスはそれぞれ異なり、初めて新しい知識や経験を獲得することは、組織に長期的な影響を及ぼすことになる」とラックマン氏は語った。

Lachhman 氏は、次のような一般的な保守および管理タスクの例を挙げています。

• クラスターとそのインフラストラクチャのパッチ適用またはアップグレード。
• ワーカーノードを追加および削除します。
• Istio や Traefik などのサービス メッシュ ツールなどの新しい機能を導入する。
• 特に、Kubernetes を使用するチームが増えるにつれて、明確に定義された名前空間の分類を確立します。

名前空間はなぜ重要ですか?複数のユーザー間でのコンテナ内のリソースへのアクセスを保護するのに役立ちます。

3. Kubernetes を成功させるには適切なインフラストラクチャが必要

Kubernetes を長期的に成功裏に管理するための基本的な要件の 1 つは、ハイブリッド環境やマルチクラウド環境などの適切なインフラストラクチャを採用することです。

「チームが犯している間違いは、俊敏性を求めるあまり Kubernetes に移行し、その結果、当初の決定のきっかけとなった運用上の成果を実現する Kubernetes の能力が損なわれてしまうことです」と Rao 氏は言います。 「このアプローチは、ある意味、自滅的です。どんなシステムでも、その最小の要素の俊敏性だけが重要です。そのため、俊敏性の低い仮想マシン環境を動かすのと同じハードウェアとソフトウェア上に保存された静的なデータセンター環境で Kubernetes を実行している場合、Kubernetes を真剣に受け止めなければ、期待するメリットは得られません。」

Zettaset のエンジニアリング担当副社長 Maksim Yankovskiy 氏は、ストレージは計画が必要となる可能性のあるインフラストラクチャの特定のサブセットであると述べています。たとえば、ステートフル コンテナーには特別なストレージの考慮事項が伴います。

「ワークロード用のストレージを計画することは非常に重要です」とヤンコフスキー氏は言います。 「一部のワークロードでは、特殊なストレージや、アプリケーションごとのストレージ パラメータの調整が必要になる場合があります。すべてのストレージを Kubernetes で管理する必要はありません。」

ラオ氏はまた、チームがより俊敏になるために Kubernetes を導入する際に見落としがちな特定の領域の例としてストレージを指摘し、これが管理側で頭痛の種になる可能性があると述べました。

「私は Kubernetes 上でデータ サービスを実行している多くの顧客と仕事をしていますが、よく聞くのが『Kubernetes 上で MongoDB を実行しようとしたが、いつも SAN に問題があった』という声です」と Rao 氏は言います。 「SAN は利用可能ですが、Kubernetes の規模、密度、動的性質に合わせて設計されていません。Kubernetes を最大限に活用するには、効果的に実行するために必要なインフラストラクチャを提供する必要があります。静的なインフラストラクチャのみを提供すると、Kubernetes は機能しません。」

4. Kubernetesの信頼性は企業に自信過剰を招きかねない

Rao 氏が冒頭で指摘したように、Kubernetes の自己修復機能と信頼性機能は大きな魅力の 1 つですが、これを健全性を無視する言い訳にしてはいけません。たとえば、適切な監視が確実に行われるようにする必要が依然としてあります。

「機能不全のサービスを修正するためにKubernetesの信頼性機能に頼らないでください」とヤンコフスキー氏は言う。 「Kubernetes が障害が発生したポッドを自動的に再起動する優れた機能を備えているからといって、アプリケーションの実行時エラーを監視する必要がないということではありません。」

ビジネスが発展し成長するにつれて、ログ記録はもう一つの重要な管理要件になります。

「Kubernetes クラスターは高度に分散されているため、Kubernetes クラスターを展開する最初のステップには、集中ログ機能の計画を含める必要があります」と Yankovskiy 氏は述べています。 「パフォーマンスを監視したり問題を診断したりするときに、単一ノードのログにアクセスするのはスケーラブルではありません。優れたログ管理システムは、強力な Kubernetes 管理の基盤の 1 つです。」

Red Hat のテクニカル エバンジェリストである Gordon Haff 氏は次のように付け加えています。「Kubernetes にデプロイされるクラウド ネイティブ アプリケーションは基本的に分散アプリケーションであり、モノリシック アーキテクチャの実行に慣れている IT 部門は、それらのアプリケーションについてあまり経験がない可能性があります。Kubernetes の周辺にあるオープン ソース プロジェクトのエコシステムには、監視、ログ記録、分散トレースなどが含まれます。ただし、大規模な DIY プロジェクトに着手するのではなく、そのツールがすでに Kubernetes に統合されているプラ​​ットフォームが必要な場合があります。スタッフも、新しいクラウド ネイティブ アプリケーション開発手法のトレーニングから恩恵を受ける可能性があります。」

一般的に、チームは、Kubernetes を他の重要なシステムと同様に保守および改善する必要があるツールではなく、万能薬と見なすと、問題に直面する傾向があります。

「組織には複数の管理者がいて、トポロジーは定期的に変更されるが、Kubernetes を使用する場合はネットワーク遅延の影響を受けない可能性がある」と Lachhman 氏は言う。

5. 実験と退屈を定期的に調整する

Lachhman 氏は、Kubernetes の使用自体はもはや実験的なものとは言えないと指摘しました。このプロジェクトはほぼ 5 年間開発されており、現在では安定した信頼性の高いプラットフォームとなっています。そうは言っても、エコシステムは常に進化しています。オペレーター、クラスター API、GitOps、前述のサービス メッシュ ツールなどについて考えてみましょう。 Lachhman 氏は、Kubernetes チームはイノベーションと制御を切り替える方法を決定する必要があり、これは企業経営における考慮事項であると述べました。

一方で、ほとんどのチームは、特に導入の初期段階では、「退屈」という方向に傾きがちです。

「アプローチをシンプルにすることで、CNCF の最新ベータ版や特別利益団体 (SIG) に参加していなくても、Kubernetes のワークロードに悪影響がないことがわかります」と Lachhman 氏は言います。 「一方で、実際の問題を解決できるかもしれない新機能を見逃したくはありません。そのため、Kubernetes 内でより実績のあるアプローチと新しいアプローチのオプションを比較検討して、自分にとって何が適切かを判断する必要があります。」

6. 固定的な開発はコンテナやオーケストレーションと相性が悪い

最新の IT ツールは、最新の IT プラクティスと文化と組み合わせて使用​​すると最適に機能します。これは、技術管理の問題であると同時に、人材管理の問題でもある可能性があります。

「Kubernetes は迅速な開発と展開が重要です」と Zettaset の Yankovskiy 氏は述べています。 「Kubernetes のメリットを最大限に享受するには、組織によっては DevOps モデルへの移行が必要になる場合があります。」

この原則はアプリケーション自体にも適用されます。すべてのものがコンテナとオーケストレーションに適しているわけではなく、「リフト アンド シフト」は、従来のアプリケーションをコンテナに移行して Kubernetes で実行するための最善の戦略とは限りません。実際、このアプリケーションをまったく移行しない方がよい選択肢かもしれません。

「すべてをKubernetes上で実行する必要はありません」とヤンコフスキー氏は言う。 「Kubernetes は仕事のためのツールです。多くの用途に便利ですが、従来のアプリケーションの多くがコンテナに移行するにつれて、すべてをコンテナ内で実行する必要があるわけではないことを理解することが重要です。」

7. できることをやる

企業が学習能力に優れていることは良いことですが、その限界を知ることもまた良いことです。そうしないと、Kubernetes を長期的に管理することが困難になる可能性があるため、外部の支援を求めるタイミングを知っておく必要があります。

「さらなるスキルの獲得を目指すことは避け、複雑さを軽減するタイミングを知ってください」とラックマン氏はアドバイスする。 「独自のクラスターをゼロから構築し、すべてのデプロイメントで適合テストを実行することは、ゴールドスタンダードのように思えるかもしれませんが、ほとんどのワークロードでは、その複雑さを PaaS または Kubernetes ベンダーにオフロードすることは悪い考えではありません。」