本番環境と開発環境、Kubernetes に関する 4 つのよくある誤解

[編集者注] コンテナと Kubernetes の IT 管理チームが実稼働環境にローカルの変更を展開する場合、多くの学習に直面することがよくあります。

最近、Kubernetes を試用する際によく見られる誤解をいくつか解消しました。最も大きな誤解の 1 つは、Kubernetes を本番環境で実行することは、開発およびテスト環境を実行することと何ら変わらないというものです。

回答：それらは異なります。

Avi Network の共同創設者兼 CTO である Ranga Rajagopalan 氏は、次のように述べています。「Kubernetes、コンテナ、マイクロサービスの場合、実験環境と実稼働環境の間には大きな違いがあります。単に実行することと、安全かつ確実に実行することの間には違いがあります。」

Ranga Rajagopalan 氏の意見には重要な点があります。それは、上記の問題は Kubernetes だけでなく、コンテナやマイクロサービスにも当てはまるということです。コンテナのデプロイは比較的簡単です。コンテナ（コンテナ化されたマイクロサービスを含む）を運用環境で運用およびスケーリングする際に、複雑さが生じます。

コンテナとコンテナ オーケストレーション ツールは通常、セットで提供されます。 New Stack が以前実施した調査では、組織が運用上の課題を解決するためにさらに強力なテクノロジーを求めており、コンテナが Kubernetes の人気を牽引していることが分かりました。他のツールも存在しますが、Kubernetes はすぐに、選択されるオーケストレーション ツールの代名詞になりました。 Rajagopalan 氏が述べたように、サンドボックスで Kubernetes を実行することと本番環境で Kubernetes を実行することには大きな違いがあります。

通常、IT プロフェッショナルとチームは小規模な Kubernetes 環境を運用します。この環境が本番環境に移行すると、これらの人々は多くのことに直面し、学ぶことになります。 「本番環境に移行する前に、こうしたよくある誤解を解消しておく必要があります。IT リーダーとチームが知っておくべきことは次のとおりです。」

誤解1: 開発環境とテスト環境でKubernetesを実行すると、運用要件を完全に理解できるようになります。

現実:開発環境とテスト環境で Kubernetes を実行すると、運用環境の運用負荷に対処することなく、いくつかのショートカットを実行できます。

StackRox のプロダクト担当副社長 Wei Lien Dang 氏は、「開発・テスト環境と本番環境の最大の違いは、運用とセキュリティにあります。運用・テスト環境では、クラスターのダウンタイムをまったく心配する必要はありません。」と考えています。

Portworx の共同創設者兼 CEO である Murli Thirumale 氏は、開発およびテスト環境と本番環境の違いを、俊敏性と信頼性の高い高性能な俊敏性に例えています。

「開発チームの目標は、新しいアプリケーションやコードを開発およびテストする際にアプリケーションの俊敏性を実現することです。一方、運用担当者の目標は、アプリケーションとデータの信頼性、拡張性、セキュリティ、パフォーマンスです。後者には、強力でエンタープライズ グレードの、テスト済みで実証済みのプラットフォームが必要です。」

Kubernetes (または一般的なコンテナ) を本番環境に導入するには、自動化が急務となっています。

Coda Global のアーキテクトである Ranjan Bhagitrathan 氏は、「運用クラスターは自動化を通じて展開する必要があります。運用クラスターは、運用環境全体の一貫性を実現するために複製可能である必要があり、複製可能性は災害復旧にも役立ちます」と考えています。

Bhagitrathan 氏は、バージョン管理が実稼働環境の運用にとって非常に重要であると考えています。 「サービス展開構成ファイル、ポリシーなど、すべてをバージョン管理し、可能であれば、インフラストラクチャをコードとして実装するコマンドをコード化します。これにより、環境が同じであることが保証されます。また、コンテナ イメージがバージョン管理されていることを確認してください。イメージに「最新のイメージ」などの名前をタグ付けするだけでは混乱を招きかねません。」

誤解2: 信頼性とセキュリティは確保されている

現実: Kubernetes を非本番環境でのみ実験した場合。信頼性とセキュリティが得られていないか、まだ得られていない可能性があります。

幸いなことに、生産に入る前に計画とアーキテクチャ設計が必要なので、最終的にはそこに到達できます。

AquaSecurity の共同創設者兼 CTO である Amir Jerbi 氏は、「明らかに、本番環境では、パフォーマンス、スケーラビリティ、高可用性、セキュリティといった課題がより深刻です。そのため、アーキテクチャ フェーズで本番環境の要件を計画し、セキュリティ、スケーラビリティ制御、Helm チャートを Kubernetes デプロイメントの定義に統合することが極めて重要です」と考えています。

Dang 氏は、テスト開発環境が過信につながる可能性がある例を挙げました。

「テストおよび開発環境では、すべてのネットワーク ポートがオープンになっていると便利です。すべてのサービスが相互に接続できるからです。Kubernetes は、デフォルトですべてのネットワーク接続をオープンに設定します。しかし、これは成熟した本番環境ではありません。本番段階に入ると、ダウンタイムや大規模な攻撃がビジネスにリスクをもたらします。」

「作業がコンテナやマイクロサービスに移行するにつれて、信頼性と可用性に優れたシステムを構築することは価値のある取り組みになります。オーケストレーション ツールはそれに役立ちますが、自動ではありません。セキュリティについても同じことが言えます。」

「Kubernetes に対する攻撃を軽減するためには、やるべきことがたくさんあります。ネットワーク ポリシーを適用し、サービスを接続する必要のあるサービスだけに制限することで、最小権限モデルを強制することが重要です。」

実稼働環境では、コンテナ イメージのセキュリティ脆弱性が急速に深刻化する可能性があり、脅威は限定的であるか、まったくローカルではない可能性があります。 （一方、脅威は局所的には限定的であるか、存在しない可能性があります。）

Bhagirathan 氏は、「コンテナ イメージで使用されるベース イメージに注意し、信頼できる公式イメージを使用するか、可能な場合は独自のイメージを作成してください。不明なイメージを使用すると、サービスを迅速に実行できる場合がありますが、セキュリティの問題も発生します。たとえば、Kubernetes システムが他の人の Bitcoin マイニングに貢献することは絶対に望ましくありません。」と述べています。

Red Hat のセキュリティ戦略家である Kirsten Newcomer 氏は、コンテナ スタック レイヤー (コンテナ ホストやレジストリなど)、コンテナ ライフサイクル (API 管理) など、10 のレイヤーを通じてコン​​テナ セキュリティについて考えることを推奨しています。レイヤー 10 の詳細と、それが Kubernetes などのコンテナー オーケストレーション ツールにどのように適用されるかについては、Newcomer のポッドキャストまたはホワイト ペーパー (https://www.redhat.com/en/enga ... yaAAA) を参照してください。

誤解3: オーケストレーションツールはスケーリングを容易にする

事実:多くのソフトウェア専門家は、Kubernetes のようなコンテナ オーケストレーション エンジンがコンテナのスケーラビリティに不可欠であることに同意していますが、特に初めて本番環境で使用する場合は、オーケストレーション ツールによってスケーリングが即座に簡単になると考えるのは間違いです。

Sumo Logic のシニア テクニカル プロダクト マネージャーである Frank Reno 氏は、「自動スケーリングによってすべてが変わります。データはますます大きくなり、監視システムもデータ量に合わせてスケーリングする必要があります。Kubernetes のすべてのコンポーネントは、実稼働環境で実行する前に十分に理解することはできません。結局のところ、Kubernetes システムの正常な動作を確保するには、API サーバーやその他の制御コンポーネントを自動ではなく需要に応じてスケーリングする必要があります。」と考えています。

開発環境やテスト環境では物事が単純になりすぎますが、実際の環境ではさまざまな要件が必要となり、常にメンテナンスを行う必要があります。

「特定のリソースへのアクセスを確保したり、リクエストを制限したりするなど、開発とテストの基本の一部を省略するのは簡単です」とリノ氏は語った。 「本番環境でそれをやらないと、あなたの一日は終わりです。」

クラスターのスケールアップまたはスケールダウンは、ローカルで実験しているときには簡単に思えるかもしれませんが、実稼働環境ではスケールアップが非常に困難になる良い例です。

「開発やステージングのクラスターとは対照的に、本番クラスターではスケーリングに関してより多くの問題点があります」と、WhiteSource の CEO である Rami Sass 氏は述べています。 「Kubernetes ではアプリケーションの水平スケーリングは非常に簡単ですが、DevOps [チーム] が考慮する必要がある他の側面、特にサービスをオンラインにしたままインフラストラクチャをスケーリングする点があります。脆弱性とセキュリティを担当する主要なサービスとアラート システムがクラスターのノード全体に分散され、スケールダウン時にデータが失われないようにステートフルになっていることを確認することが重要です。」

他のあらゆる課題と同様に、適切な計画とリソースの使用が重要です。

「スケーリングのニーズを理解し、それに合わせて計画を立て、そしてさらに重要なのは、それをテストすることです。」 Coda Global のバギラサン氏はこうアドバイスします。 「本番環境では、より高い負荷を処理できる必要があります。」

誤解4: Kubernetesがどこで実行されるかは問題ではない

現実:開発者のラップトップで Kubernetes を実行することと、本番環境で Kubernetes を実行することの間に違いがあるのと同様に、環境によって違いが生じます。

「Kubernetes がローカルで問題なく動作するなら、どこでも問題なく動作するだろうと想定するのはよくある誤解です」と、Bitnami の CEO 兼共同創設者であるダニエル・ロペス氏は述べ、クラウド プラットフォーム間の違いを指摘して、この想定が間違っていることを証明しました。 「Kubernetes は一貫した環境を提供するのに効果的ですが、ベンダー間で大きな違いがあります。」

ロペス氏はまた、本番環境での展開には、監視、ログ記録、証明書管理、資格情報など、ローカルでのみ機能するコンポーネントだけでなく、他のコンポーネントも必要であると指摘しました。これらの要素を考慮する必要がありますが、これが開発/テスト環境と本番環境の間のギャップが広がる主な問題の 1 つです。

これは、Kubernetes だけでなく、コンテナやマイクロサービス、さらに広くはハイブリッド クラウドやマルチクラウド環境でも考慮する必要がある包括的な問題でもあります。

「パブリック・プライベートの導入は、ロードバランシングやファイアウォールなど、必要なサービスの多くが独自のものであるため、紙に書かれている以上に複雑です。ラボでうまく機能するコンテナが、異なるツールを備えたクラウド環境で実行すると、まったく機能しないか、少なくとも安全ではない可能性があります」と、Avi Networks の Rajagopalan 氏は述べています。 「だからこそ、Istio のようなサービス メッシュ テクノロジーが注目を集めているのです。コンテナがどこで実行されても同じアプリケーション サービスが提供されるので、インフラストラクチャについて考える必要がありません。これがコンテナの最も重要な点です。」