コンテナの実施：KubernetesとIstioの連携方法

DevOpsツールとアプローチに関する会議はすでに明日です。つまり、最後のインタビューの時が来ました！ 今回、Google開発チームのリーダーの1人にKubernetesとIstioのバンドルの作業についていくつかの質問をしました。これらのリリースは来年初めに予定されています。



Craigが、なぜ1台のマシンにもコンテナで展開する価値があるのか​​、オーケストレーションシステムを接続するタイミング、Kubernetesが持つ代替手段、そして今後の期待をお伝えします。 詳細-カットの下。









Craig Box（クレイグボックス）-エキスパートであり、Google Cloudのいずれかの部門の責任者。 彼の責任には、プラットフォームの操作、ユーザーレビューの収集、エンジニアとのやり取りが含まれます。 システム管理者から始まり、開発、実装、DevOps、コンサルティング、管理に切り替えました。



レポートについて少し教えてください。 あなたが話しているその束は、すでに生産の誰かによって使用されていますか、それとも概念ですか？ lstioはどれくらい成熟していますか？



クレイグボクシング： Istioは、ワークフローを開発から切り離すオープンソースサービスネットワークです。 バイトやパケットではなく、サービスのネットワークとして想像できます。



モノリシックプロセスからマイクロサービスにアプリケーションを転送するとき、多くの分散エンドポイントのように、常に確実に動作するとは限らないネットワークを実装します。 一部の企業、特にNetflixは、各マイクロサービスに含まれるべきライブラリを使用して、マイクロサービスのネットワークの問題を解決しました。 マイクロサービスでは各コンポーネントを任意の言語で開発できるため、ライブラリを複数の言語でサポートする必要があり、すぐにこれが追加の問題になりました。



Istioでは、既存のサービスと新しいサービスを任意の言語で単一の方法で管理できます。 任意の言語のマイクロサービスを管理、監視、保護し、どこにでも展開できます。



管理者はルールを定義します（たとえば、「バックエンドトラフィックの10％をサービスに送信する」または「AとB間のすべてのトラフィックがTLS相互暗号化を使用して実行されるようにする」）。 Istioは、これらのルールを実施するようにプログラムされた各サービスの前にプロキシサーバーを実装します。 また、何も定義しなくても、IstioをKubernetesクラスターにインストールした後、すぐに豊富なトラフィックモニタリングのコレクションを入手し、エンドポイント間で分散トレースを提供できます。



Istioが使用するプロキシサーバーはEnvoyと呼ばれます。 Matt Klein率いるLyftチームによって書かれました。 Lyftはプロジェクトで長い間Envoyを使用してきましたが、この間にさまざまなサイズのシステムでその動作をテストしました。



Istioコミュニティには当初、Google、IBM、およびLyftが含まれていましたが、他の多くのメンバーに参加した後、バージョン0.2がリリースされました。 私たちはそれを「ベータ版」とみなし、今年の終わりにバージョン0.3の限定的な産業利用を計画し、リリース1.0は2018年に予定されており、さらに多くの環境をサポートします。



IstioはもともとKubernetesを念頭に置いて設計されており、Kubernetesはもちろん、すぐに使える成熟した製品です。 調査会社のRedmonkは、KubernetesはFortune 100企業の54％で使用されており、コンテナ会社全体の75％を占めていると主張しています。



-ほとんどのDevOpsプラクティスとは異なり、オーケストレーションシステムを使用する必要性は、特に比較的小さなチームやプロジェクトの場合、必ずしも明らかではありません。 それらはすべての人に常に必要ですか、それとも同様のシステムが登場し、マイクロサービスと多数のマシンの場合にのみメリットがありますか？



Craig Boxing： 1台のマシンにサービスが1つしかない場合でも、コンテナを使用することには利点があります。すべての依存関係を1つのアトミックユニットにデプロイできます。いつでも、すべての変更を簡単にロールバックできます。



コンテナが1つしかない場合でも、Kubernetesはこのコンテナのライフサイクルを管理するための優れたAPIであり、任意のマシンで実行されます。 メモリやネットワークなど、アプリケーションよりも低い抽象化を処理し、展開ツールを使用して簡単に構成できるAPIサーバーを提供します。



これで、環境間を移動できるポータブルアプリケーションができました。 アプリケーションを構成したら、スケーリングに進むことができます。



-同様のオーケストレーションシステムなしでプロジェクトが最初に開始された場合、現在必要なものをどのような兆候で理解できますか？



クレイグボクシング： Kubernetesのようなシステムは、最初から最後までAPIによって管理されます。 Google Container Engineなどのサービスを使用したクラスターの作成から、そのクラスターでのアプリケーションのデプロイと更新まで、すべてを自動化できます。



人々がこれを行う最も一般的な理由の1つは、変化率を上げることです。 これは次のようなものです。コンテナ、オーケストレーション、およびマイクロサービスをクラウドに移動すると、単一の展開のリスクが軽減されます。 これにより、継続的な運用が保証されます。 これで、カナリア展開などのテンプレートを使用してアクティブ化されるプロセスに自信が持てます（最初はトラフィックの1％が新しいサービスに、次に5％、次に20％など）。 何か問題が発生した場合は、戻ることもできます。



お客様からは、1か月に1回の展開から1日に数十回まで展開できると言われました。 これは、新しいコードがより高速になり、最終的にビジネスプロセスのより柔軟な管理につながることを意味します。



-Kubernetesに代わる深刻な選択肢はありますか？ または、彼のモデルは非常に優れており、原則として必要ではないので、最終的には1つしかありません。



Craig Boxing： Kubernetesは、Googleが作成したクラスタリングモデルの進化版です。 この分野の他のシステム、たとえばMesosに影響を与えた作業に関するドキュメントを公開しました。



Kubernetesが登場したのとほぼ同時期に、他の同様のシステムが登場しました。 それらの多くはすぐにKubernetesに切り替えました（たとえば、OpenShift、Deis Workflow、最近ではRancher）。



GoogleがKubernetesを作成してオープンライセンスでリリースすることを決定した理由の1つは、すべてのプロバイダーで使用できる標準APIが誰もが必要としていたためです。



KubernetesはLinux for the Cloudと呼ばれます。 Unixが必要な場合、Linuxはある意味で事実上の選択ですが、クローズドソースの世界やWindowsはもちろんのこと、さまざまな場面で他のオープンソースオペレーティングシステムのエコシステムが存在します。



同様に、ステートフルなWebサービスからビッグデータとGPUを使用したMLモデルのバッチワークロードまで、あらゆる種類のアプリケーションを管理できるKubernetesの素晴らしいAPIセットを作成しました。 また、Kubernetesで拡張機能を作成するのに多くの時間を費やしました。これにより、考えもしなかった種類のオブジェクトを定義できます。 Kubernetesはエコシステムの中心であり、拡大できるものであると考えています。



-既存のオーケストレーションの決定を維持するのはどれくらい難しいですか？ すぐに入力して起動し、忘れることはありますか？ または、一定のチューニング、クラスターの崩壊、その他の問題がありますか？



Craig Boxing：各ユーザーには、クラスターを使用する独自の理由があります。 最大の電力利用のためにそれらを共有し、長時間動作させたい場合があります。 他のユーザーは、必要な場合にのみそれらを含め、異なるビジネスユニットに独自のクラスターを与えたいと思うでしょう。 一定数のマシンで作業する人は、必要に応じてマシンを自動的に追加できるため、クラウドで作業する人とは使用方法が異なります。



Kubernetesはすべての状況で適切に動作するように設計されており、当社の製品であるGoogle Container Engineを使用すると、クラスターを3分未満でデプロイできます。



-既存のオーケストレーションシステムの助けを借りて解決できない、または困難なタスクは何ですか？ 彼らの開発はどこに向かっていますか？



Craig Boxing：コンテナオーケストレーションシステムは、スケーラブルなシステムでの一般的な動的ワークロードに適しています。 1台のマシンで1つの商用データベースを実行し、このマシンのすべてのリソースを使用する場合は、何も変更しないことをお勧めします。 このサーバーが故障した場合、移動にかかる労力と費用は、修理にかかる労力と費用よりも大きくなる可能性があります。 これを念頭に置いて、クラスター内の外部サービスに単純に接続することをお勧めします。



同様に、Google BigQueryなどのマネージドサービスがある場合、クラスターでデータウェアハウスを開始する必要はありません。



Istioは、すべてのアプリケーションがKubernetesで実行されるわけではないことを知っています。 バージョン0.2では、仮想マシンと実マシンの両方で実行されているサービスを追加できます。



OracleはコンテナでOracleデータベースをホストするスクリプトを公開しましたが、Microsoftはさらに一歩踏み込んでSQL ServerイメージをDocker Hubにアップロードしました。 そのようなワークロードを移動したい場合、それは可能な範囲を超えています！



-ステートフルサービスについてはどうですか？ 普遍的なメカニズムの出現を期待すべきですか？



Craig Boxing： KubernetesのMVPはステートレスWebサービスをホストしていましたが、ステートフルワークロードを実行できるようにするために必要なことを常に考えていました。



各メンバーに序数（番号付き）識別子と個別のリポジトリを提供する「StatefulSet」の概念に取り組みました。 さらに、クラスターにアイテムを追加または削除するために何が必要かを知っているアプリケーションの「ステートメント」を作成できます。



Kubernetesコミュニティは、CassandraやMongoDBなどの一般的なオープンソースアプリケーション用のテンプレートを多数開発しており、多くの企業が従来のエンタープライズアプリケーションをコンテナーに移行しています。 すべてのコミュニティが、Kubernetesを一流のサポートされた展開プラットフォームとして使用することを願っています。

---

マイクロサービス管理の問題が関連している場合は、Craig Boxの講演「 DevOops 2017でKubernetesとIstioを使用 してマイクロサービスを管理する」をお読みください 。



また、あなたはおそらく会議を含む他のスピーチに興味があるでしょう：

• k8の拡張 （ニコライリジコフ、ヘルスサムライ）
  
  
• Kubernetesの本番アプリケーションのトラブルシューティングとデバッグ、別名The Failing Demo Talk （Raysang、GoogleおよびBaruch Sadogursky、JFrog）
  
  
• SmartMonitoring-Odnoklassnikiのビジネスロジックの監視 （Sergey Sharapov、Odnoklassniki）