独自のインフラストラクチャ上のKubernetes：プライベートクラウドの長所と短所

読者の皆様、良い一日を！



この記事では、NeoflexのチーフアーキテクトであるIgor Kotenkoが、エンタープライズインフラストラクチャにコンテナ化プラットフォームを展開した経験を共有します。







企業が通常オンプレミスソリューションを選択する理由は、多くの場合非技術的であり、多くの場合、資金調達に関連しています。誰かが会社の資本化（独自のサーバーの購入）を優先して運用コスト（外部クラウドの支払い）を削減しようとしています。誰かがすでに堅固なハードウェアリソースを持っており、それらをマイクロサービスアーキテクチャで使用したいと考えています。



実装の詳細に移る前に、用語に目を向けましょう。



「雲」という用語は非常に混雑していると考えられています。さまざまなタイプのクラウドソリューションを区別するのが通例です。

• サービスとしてのインフラストラクチャ（IAAS）-ハードウェア（通常は仮想）。
• サービスとしてのソフトウェア（SAAS）、たとえばDBAS-サービスとしてのデータベース。
• サービスとしてのプラットフォーム（PAAS）;
• サービスとしてのアプリケーション（AAAS）。

同時に、レイヤーが相互に基づいていることを妨げるものは何もありません。明らかに、プラットフォームまたはソフトウェアの下にインフラストラクチャがあります。



「プライベートクラウド」という用語については、いくつかの混乱があります。これはオンプレミスクラウドと呼ばれることもあり、ネットワークセグメントが完全に分離されたリースインフラストラクチャに展開されることもあります。暗号化されたメモリとディスクを備えた仮想マシンについての言及もありましたが、メモリダンプはプロバイダーにあなたの情報へのアクセスを許可しません。この記事では、社内で展開されるソリューションについて説明します-オンプレミス。



プライベートクラウドを導入する場合、それらはパブリッククラウドと同じであることが期待されますが、より安価で、より安全で、より信頼性があります。したがって、多くの人はプライベートクラウドの方が先験的に優れていると考えています。多くの場合、専門家は選択したバージョンのKubernetesまたはOpenshiftを展開するだけで、ここで作業が完了すると信じています。



オンプレミスクラウドに実装するときに企業が期待するもの：

1. 低リソースコスト。使用した分だけ支払うからです。
2. できるだけ早くリソースを追加して返す機能。
3. 耐障害性。サーバーがクラッシュし、代わりに別のサーバーが自動的に提供されました。
4. 低メンテナンスコスト。

これはパブリッククラウドでどのように達成されますか？



原則として、プロセスの自動化、規模の経済性（バルクで安価）、および異なる消費者間でのリソースの共有によります。



プライベートクラウドのコンテキストでこれらの約束を見てみましょう。



1.従来のインフラストラクチャと比較して低リソースコスト。



実際、そうではありません。同じソフトウェアが同じマシンにデプロイされましたが、コンテナ内にありました。それどころか、私たちの経験では、より多くのリソースが無駄になっています。



2.リソースを非常に迅速に増減する機能。



番号。拡張するには、ハードウェアおよびソフトウェアライセンスのホットリザーブをアイドル状態に保つか、最初に不要なものを破棄する必要があります。リソースを使用しないようにすることはできますが、その場合はアイドル状態になります。



3.耐障害性。



はい、しかし多くのニュアンスがあります。サーバーがダウンしているとしましょう。別のものはどこで入手できますか？すばやくデプロイしてクラスターに追加するにはどうすればよいですか？あなたがアマゾンでないなら、あなたはリソースの無限の供給を持っていません。



4.サポートの低コスト。



少なくとももう1つのレイヤー（コンテナー化プラットフォーム）、いくつかの新しいシステムを追加しました。新しい能力を備えたスペシャリストが必要です。節約はどこから来るのでしょうか？



これらの質問をさらに詳しく調べてみましょう。プライベートクラウドは既存のレガシーシステムと共存する必要があることを覚えておくことが重要です。組織は、既存のシステムのインフラストラクチャを並行して維持し、ハイブリッドIT環境を編成することを余儀なくされています。



当然、システムの99％はゼロから構築されていません。原則として、PAASソリューションの実装前であっても、古いインフラストラクチャをサポートするための一連のプロセスと自動化があります。DevOpsプロセス、計画とリソースの所有権、監視、ソフトウェアの更新、セキュリティ-これらすべての問題は、プライベートクラウドの実装中に合意し、変更する必要があります。

DevOpsプロセスの変化

通常、独自のPAASを実装する前は、DevOpsを構築するためのアプローチは、AnsibleやChefなどの構成自動化システムの使用に基づいています。多くの場合、既製のスクリプトライブラリを使用して、ほぼすべての日常的なITプロセスを自動化できます。ただし、コンテナ化プラットフォームは、代替アプローチである「不変のインフラストラクチャ」を推進しています。その本質は、既存のシステムを変更することではなく、新しい設定でシステムの既製の仮想イメージを取得し、古いイメージを新しいイメージに置き換えることです。新しいアプローチは古いアプローチを否定するものではありませんが、構成の自動化をインフラストラクチャ層に強制します。もちろん、レガシーシステムでは古いアプローチを維持する必要があります。

インフラストラクチャ層について話しましょう

ITの事実上の標準は、仮想インフラストラクチャの使用です。実践が示すように、最も一般的なオプションはvSphereを使用することです。これには多くの理由がありますが、結果もあります。私たちの実践では、リソースのオーバーサブスクリプション（1つのスキンから7つの帽子を縫う試み）に関する頻繁な問題は、ソリューションのパフォーマンスの責任者によるこのプロセスへの制御と影響がほぼ完全に欠如しているために悪化しました。会社の部門における責任範囲の境界設定、リソース要求手順の形式化、および部門の管理のさまざまな目標により、製品環境の問題と一貫性のない負荷テストが発生しました。ある時点で、私たちの開発部門は仮想コアパフォーマンス測定ツールを作成しました。ハードウェアリソースの不足をすばやく診断します。



このようなインフラストラクチャにコンテナ化プラットフォームを配置しようとすると、既存の混乱に新しい色がもたらされることは明らかです。



オンプレミスのコンテナ化プラットフォームに仮想インフラストラクチャが必要か、それともベアメタル（鉄のサーバー上）に配置する方がよいかという問題は、長い間、非常に広く議論されてきました。仮想化システムのメーカーがロビー活動を行った記事では、パフォーマンスの低下は事実上なく、メリットが大きすぎると主張しています。一方、約10％のパフォーマンス低下を示す独立したテスト結果があります。 vSphereライセンスのコストを忘れないでください。たとえば、無料バージョンのKubernetesを安価なハードウェアにインストールして、お金を節約し、vSphereの料金を支払うにはどうすればよいでしょうか。物議を醸す決定。



OpenStackなどのオープンソースインフラストラクチャ仮想化ソリューションについて言及する価値があります。一般的に、彼はチームへの深刻な投資を必要とするソリューションと見なされていました。オープンスタックサポートチームの規模が20人から60人であるという統計が、ネットワーク上にあります。そして、これはコンテナ化プラットフォームのサポートとは別のものです！市場にはそのような専門家はほとんどいないため、コストが高くなります。このような投資は通常、非常に大量のリソースに対してのみ報われます。



社内に独自の能力を持つスペシャリストの存在を考慮することが重要です。残念ながら、ベアメタルのKubernetesのインストールは、透明性とライセンスコストの削減というメリットがあるにもかかわらず、適切なインストール自動化ツールの欠如などによって妨げられることがよくあります。将来がこのアプローチに属することを願っています。

仮想インストールとベアメタルインストールの選択に影響を与えるもう1つの側面は、鉄のサーバーの編成です。



通常、組織は特定の目的でサーバーを購入します。データセンター内のサーバーを（提供されているものから）レンタルしたり、命名法を標準化および統一したり（コンポーネントの冗長性を簡素化したり）、ハードウェアを節約したり（多くの安価なサーバー）、ラックスペースを節約したりできます。さまざまな組織でのさまざまなアプローチ。一般に、これらは、コアとメモリの数が多い強力なサーバーか、ボリュームが比較的小さいサーバーか、事前に作成されたホッジポッドのいずれかです。ただし、レガシーシステムのニーズを忘れないでください。この時点で、私たちは再び概念の矛盾に遭遇します。 Kubernetesのイデオロギーは、多くの安価なハードウェアであり、その失敗に備えています。サーバーがダウンしました-問題ではありません。サービスが別のサービスに移動しました。データは、コンテナに関連付けられているのではなく、シャーディング（複製）されています。レガシーイデオロギー-ハードウェアレベルでの冗長性。 RAIDアレイ、ディスクラック、サーバー上の複数の電源、ホットスワップ。最大の信頼性に焦点を当てます。このようなKubernetesインフラストラクチャに投資することは、不当に費用がかかる可能性があります。

, …

企業に多数のコアを搭載した高性能サーバーがある場合、それらを異なるコンシューマー間で分割する必要がある場合があります。ここでは、仮想化システムなしでは実行できません。同時に、サーバーの故障やメンテナンスのための停止の可能性を考慮する必要があります。計算は簡単です。2つのサーバーがある場合、1つに障害が発生した場合、それぞれに50％の電力予約が必要です。 -4台のサーバーの場合、1台に障害が発生した場合、25％の予約が必要です。一見、すべてが単純です。無限の数のサーバーが必要です。そのうちの1つに障害が発生しても、総容量に影響はなく、何も予約する必要はありません。残念ながら、1つのホストのリソースのサイズを大幅に削減することはできません。少なくとも、Kubernetesの用語で「ポッド」と呼ばれるすべての関連コンポーネントに対応する必要があります。そしてもちろん、小さなサーバーに押しつぶすときは、プラットフォーム自体のサービスのオーバーヘッドコストが増加しています。



実用的な目的のために、プラットフォームのホストパラメータを統合することが望ましい。実物に近い例では、2つのデータセンターがあります（DRシナリオのサポートは、容量に関して少なくとも50％のリソース予約を意味します）。次に、コンテナ化プラットフォームのリソースに対する組織のニーズと、それを標準のベアメタルまたは仮想ホストに配置する可能性が決定されます。Kubernetesの推奨事項-ノードあたり110ポッド以下。



したがって、ノードのサイズを決定するには、次のことを考慮する必要があります。

• ノードを等しくすることが望ましいです。
• ノードはハードウェアに適合している必要があります（仮想マシンの場合-複数、1つのハードウェアの場合はN仮想）。
• 1つのノードに障害が発生した場合（仮想インフラストラクチャを備えたバージョンの場合-1つのアイアンサーバー）、残りのノードにポッドを移動するのに十分なリソースが必要です。
• 1つのノードにポッドが多すぎる（> 110）ことはできません。
• 他の条件が同じであれば、ノードを大きくすることが望ましいです。

これらの種類の機能は、アーキテクチャのあらゆる側面で考慮する必要があります。



一元化されたロギング-いくつかのオプションから選択する方法は？



監視-既存の監視システムが機能しない、2つを維持する、または新しい監視システムに移行する可能性がありますか？



プラットフォームを新しいバージョンに更新します-定期的にまたは絶対に必要な場合のみ？

2つのデータセンター間のフォールトトレラントバランシング-どのように？



セキュリティアーキテクチャ、レガシーシステムとの相互作用-パブリッククラウドとは異なります。パブリッククラウドへの移行の可能性があるようにシステムを構築することを推奨することは可能ですが、これはソリューションを複雑にします。



パブリッククラウドとプライベートクラウドのリソースの計画、割り当て、所有権にほとんど違いはありません。主な違いは、リソースの量が限られていることです。パブリッククラウドで、たとえば負荷テストなどに必要な追加のリソースをいつでも使用できる場合、オンプレミスではそれらの使用順序を慎重に計画する必要があります。これは、夜間の打ち上げがある可能性があることを意味し、したがって、2行目と3行目の従業員の作業が不適切な時間に増加します。それ自体は新しいことではありませんが、プライベートクラウドの採用を待っている奇跡に対する失望の苦い味です。

「幹部がすべてを決める」

オンプレミスのコンテナ化プラットフォームの実装を計画するときは、まず、独自の能力を備えたスペシャリストが必要です。現在の労働市場には明らかに十分ではありません。さらに、そのような実装の経験がなければ、必要なすべての専門家のリストを作成することさえ困難です。



たとえば、プラットフォームを機能させるには、ストレージシステムを選択してインストールする必要があります。どちらのシステム（CEPHまたはPortworx）を選択する場合でも、プラットフォームにとって重要になります。管理者がデータベースを維持する必要があることは誰もが知っています。同様に、データストレージシステムには別のスペシャリストが必要です。残念ながら、システムを実装する前に誰もこれについて考えません！異なる製品の管理者間の違いは重要であることに注意してください-OracleDBAとMSSQLDBAの違いに匹敵します。役割ごとに少なくとも2人が必要です。従業員は休暇を取り、病気になり、さらには神が禁じ、辞めます。各コンピテンシーについても同様であり、ソリューションをサポートするために必要なコンピテンシーのリストは印象的です。



一部の普遍的な兵士のすべての能力を超えようとする試みに対して、すぐに警告したいと思います。それらのコスト、希少性、および損失のリスクは、すべての合理的な制限を超えています。



繰り返しますが、クラウドのメンテナンスは複雑なプロセスです。クラウド企業は、自分たちのパンを無料で食べません。曇りの霧の背後には、多くのテクノロジーと投資された労働力があります。



もちろん、コンサルティングサービスを利用することで、プラットフォームの実装を大幅に加速できます。経験豊富なパートナーが、多くのミスを回避し、プロセスを確立し、チームをトレーニングするのに役立ちます。ただし、プラットフォーム上でビジネスに不可欠なサービスをホストする場合は、質の高いサポートと開発を提供することも同様に重要です。さらに、現時点では、市場に存在するすべてのシステムが活発に開発されており、新しいテクノロジーが登場し、プラットフォームの新しいバージョンでは、更新前に複雑なプロセスの移行と本格的なテストが必要になる場合があります。システムの信頼性の高い運用を保証するには、強力なサポートチームが必要です。そして、あなたは継続的にそのようなチームを必要とするでしょう。



オンプレミスのコンテナ化プラットフォームの実装をいつ検討する必要がありますか？



まず、投資と収益の比率、ハードウェアと従業員のコストの量を評価する必要があります。パブリッククラウドに住むことができない正当な理由か、本当に深刻なリソース要件のいずれかが必要です。つまり、組織にとって約100コアで十分であり、サポートチームを数十人に拡大する準備ができていない場合は、パブリッククラウド、またはアプリケーションサーバーを使用した単純な構成に焦点を当てる必要があります。プラットフォームをサポートするために必要な最小チームサイズがあり、コストが報われない場合があります。ただし、リソースのスケーリングとすべてのプロセスの適切な自動化により、プライベートソリューションのメリットは非常に大きくなる可能性があります。ほぼ同じコマンドで何百ものノードを維持できます。



もう1つの選択基準は、コンピューティングリソースのニーズの変動性です。企業のビジネスプロセスが多かれ少なかれ均等なリソースの負荷を生み出す場合、独自のインフラストラクチャを開発する方が収益性が高くなります。大容量を使用する必要があるが、めったに使用しない場合は、パブリッククラウドまたはハイブリッドクラウドを検討してください。



いずれにせよ、オンプレミスソリューションを選択するときは、真剣で体系的な作業に耳を傾け、チームに投資する準備をしてください。単純なものから複雑なものへ。実装のタイミングに注意し、プラットフォームの新しいバージョンにアップグレードするときは特に注意してください。あなたの過ちではなく、他の人の過ちから得た経験を利用してください。



この記事を読んでいただきありがとうございます。この情報がお役に立てば幸いです。