Google Cloud、さくらインターネット、日本マイクロソフト、レッドハットという、それぞれの所属を超え、個人的な立場で意見を交換し、Kubernetesの可能性について語り合う場として、2018年6月に実施された「レッドハット on Cloud Day」。第二回目の今回は、"Kubernetes / Istio の最新動向"をテーマに、より具体的な事例紹介を含めたセミナー形式で開催されました。

コンテナ管理のスタンダードになりつつあるKubernetesを取り巻く現在の状況を俯瞰し、マイクロサービスのサービスメッシュ管理ツールIstio の活用ノウハウを共有する貴重な機会となった本イベントから、セッションの概要を紹介します。

セッション 1

CNCF Updates and Knative
2019 Winter version

前佛 雅人氏

さくらインターネット
前佛 雅人氏

仮想化からクラウドネイティブへ
流れの中で誕生したCNCF

複数のサーバー上のコンテナを管理するためのKubernetesが登場したのは、コンテナを効果的に使うことで、エンドユーザーの利用シーンの変化に対応した開発や安定したサービスの継続を可能にするためです。こうした動きの中で、様々な規格や仕様の乱立を回避し、ベンダーロックインのないコンテナ化、動的なオーケストレーション、マイクロサービスを目指して2015年につくられたのがCloud Native Computing Foundation (CNCF)。様々なプラットフォームでのオーケストレーション技術活用を目指すCNCFの取り組みで、物理サーバーでも、パブリッククラウドでも、Kubernetesが動く環境が整いつつあるといえるでしょう。

では、そんな整いつつあるKubernetes環境をどう活用すべきなのでしょうか。CNCFでは、Cloud Native Trail Mapや、様々なツールやソリューションを比較検討するためのCloud Native Landscapeを公開し、アプリケーションやシステムのコンテナ化、CI/CD、オーケストレーションを実現した上で、その他の機能は必要に応じて取捨選択していくことを推奨しています。また、プロジェクトの成熟度をGraduated、Incubating、Sandboxの3段階で評価し、求める環境で使えるかどうかの判断には、成熟度がどの段階にあるのかなども参考にできるようにしています。

構成イメージ

人的リソースの削減へ
フレームワークの進化に期待

Kubernetesに関連した技術として、現在、注目を集めているのが最新のサーバーレスワークロードを構築・展開・管理するためのKubernetes基盤のプラットフォーム、Knativeです。“Google Cloud Next ’18”で紹介されたKnativeは、Google、Pivotal、IBM、SAP、Red Hatがオープンソースとして開発を進めているもので、仮想サーバー化によって様々なアプリケーションを分散したとしても、依然残るリソース活用の隙間を活用するために、KubernetesとIstioとの組み合わせが提案されています。まだ開発途上ですが、アクセスに合わせたスケールの管理、ルーティングの管理を可能にすることを目指しています。

こうしたツールの進化で、コーディング不要、サーバー管理の負担の軽減も期待されています。管理に要する人的リソースがゼロになることはありませんが、人が携わる部分は少なくなりつつあります。Knativeのようなフレームワーク、コンテナ管理のフレームワークなど、進化に期待したいと思います。

前佛 雅人氏

セッション 2

本番環境を見据えたk8sのシステム構築

寺田 佳央氏

日本マイクロソフト
寺田 佳央氏

本番環境適用において
留意すべきポイント

本番環境にKubernetesを適用する場合、ベースとなるコンテナでは、いつの時点のレイテストかを判断できなくなるため、ビルド時には“latest”タグを使わないこと、できるだけ小さいイメージをつくること、パーミッションを必ず設定しておくことなどが求められます。パブリックで公開されているDocker Hubには様々なイメージがアップロードされていますが、セキュリティの脆弱性を含んだイメージがアップロードされる可能性もあります。パブリックのイメージを利用する場合は、セキュリティ・チェックを行い利用しましょう。

Kubernetes関連では、利用するKubernetesのバージョンを強く意識しましょう。Kubernetesのバージョンの違いによってできる事、できない事、さらにはマニュフェストの設定ファイルの書き方も大きく異なります。どのバージョンを利用し、どの設定が正しいのかを理解することがとても重要です。Deployment YAML の設定で、よく忘れがちなの重要項目はCPUやメモリーのリソースの設定です。この設定は他のサービスに影響を及ぼさないようにするために必要です。また、labelやselectorを理解することも重要です。同じアプリケーションの異なるバージョンを同時に動かしたり切り替えたりすることが容易にできるようになります。Serviceでは、Typeに極力LoadBalancerを指定せずClusterIPで設定する事を推奨します。パブリックにサービスを公開したい場合はIngress経由で公開する事をご検討ください。

Kubernetesのエコシステムは急速に拡大しており、3rd Partyでログ管理をはじめとする運用・管理ツールなどが日々開発されてますが、すべてKubernetesのエコシステムだけで構築する必要ありません。運用・管理を楽にするためにシンプルなシステム構築を心がけてください。たとえば本番環境でデータベースを扱う際、外部の RDBMS を利用した方が運用・管理が容易になる場合は、そちらを選択することも重要です。どのような構成が開発時、運用時に適しているかを十分に検討してください。

またバージョン・アップも注意して行う必要があります。私ならば既存のクラスターを残したまま新しいクラスターをつくり、動作確認をした後、リクエストを新規クラスターに切り替えるといった方法をとるでしょう。

VNet 経由でManaged DB の利用のススメ

Kubernetesを前提にせず
適材適所の考え方を

Azureでは、ウィザードで入力をしていくことで、簡単にKubernetes環境をつくることができます。リモートデバッグや、ノードの情報、コンテナの起動状況、CPUやメモリの情報などを確認することができるポータル画面、診断ツールも用意されていて、CI/CD環境作成機能を含め、基本的には無料で利用可能です。KubernetesでPODを構築するためには、仮想マシンのリソースの運用管理が必要になりますが、この運用管理における取り組みとして、Microsoftでは、外部のサーバーレス環境におけるポッド構築をサポートするプロジェクト(Virtual Kubelet:https://github.com/virtual-kubelet/virtual-kubelet/tree/master/providers/azure)もスタートしています。

コンテナを動かすための環境はKubernetesだけではありません。最初からKubernetesありきではなく、適材適所で使う。Kubernetesの良い機能だけを、便利に使うという感覚で取り組むべきかと考えています。

寺田 佳央氏

セッション 3

GCPで実現する
クラウドネイティブアプリケーション

福田 潔氏

Google Cloud
福田 潔氏

あらゆる環境下で
同一の体験を提供するために

ある調査によると80%の企業がハイブリッドクラウドを採用すると言われています。企業がオンプレミスを含めて複数のクラウド基盤を使うことは、管理コストの増大という課題を伴います。これをオープンテクノロジーで解決しようというのが、オープンソースであるKubernetesとIstioを中心としたCloud Services Platform(CSP、β版)です。オンプレミスでもクラウドでも同じ操作方を提供することで、基盤が異なることによる管理負荷の増加を防ぎます。例えば、AKSで立ち上げたクラスターであっても、GKEで立ち上げたクラスターであっても、OpenShiftで立ち上げたクラスターであっても、同じコマンドで同じ操作で制御することが可能です。

CSPにおいて基盤レイヤに位置づけられるのはKubernetesです。Kubernetesをベースにサービス間のやり取りであればIstioが、サーバレス基盤の実現であればKnativeがその役割をにないます。

Cloud Services Platform

エンタープライズレベルに対応
外部との連携も視野に開発が進む

Google Cloud Platform(GCP)が提供するGoogle Kubernetes Engine(GKE)は、Kubernetesのフルマネージドサービスです。マスターノードとワーカーノードで構成されるKubernetesのクラスターをフルマネージドで提供します。VMとして提供されるノードは、プリエンプティブルVM(中断される可能性があるVM)を使うことでクラスタの稼働コストを大幅に削減することができます。安全性を高めるという観点でContainer-Optimized OSというコンテナ実行に特化した軽量OSがデフォルトとして採用されます。Stackdriver による、ログ収集、モニタリングも可能です。

GKEのリリースは2015年です。エンタープライズのユーザーの拡大に伴い、セキュリティの対応が強化されています。通常クラスタではノードにパブリックIPが付与されますが、プライベートIP空間に閉じ込めることでインターネットから隔離することができるプライベートクラスタ。、可用性向上のためのリージョナルクラスタ。、ロードバランサーからPodを認識することで、コンテナネイティブなロードバランスが可能になる、Network Endpoint Group。このような新しい機能が続々と提供されます。

現在、Google では、Istioとの連携のみならず、GCPの外にあるIstioアプリケーションの制御も視野に開発を進めていて、将来的に、Istio単体では難しいグローバルロードバランス機能や、ヘルスチェックの中央管理、トラフィックベースのオートスケールなどの機能も提供する予定です。

福田 潔氏

セッション 4

Istioのつかいどころと
OpenShift Service Mesh概要

須江信洋

レッドハット
須江信洋

プロキシプロセスとして動作
アプリ埋め込みの負担を軽減

Istioは、モノリシックなアプリケーションをマイクロサービス化して分散システムとした際、管理が難しいマイクロサービス間の通信を制御するサービスメッシュの機能を提供します。Kubernetesでは、それぞれのポッドは同じサーバー上にあるかのように振る舞うことができますが、Istioは、このポッドにプロキシソフトウェアEnvoyを配置し、EnvoyがノードのIPテーブルを書き換えることで、サービスの間の通信を横取りする形でルーティングルールやポリシーなどを収集します。アプリケーションに埋め込むのではなく、プロキシプロセスとして動かすサイドカーパターンといわれる仕組みです。

Envoyを各サービスに配置することで、Istioは、サービス基盤の運用の自動化、サービス間の通信に関わる作業の効率化、動作不良の管理などを支援し、サービス停止を低減するとともに、パフォーマンスや様々なメトリクスの監視、ログの監視などの役割を担うことになるわけです。また、Envoyによって通信を暗号化することも可能になりますし、ルールベースだけでなく、通信の内容に沿ったルーティング制御などの機能を活かしたCI/CDにおける継続的デリバリーのツールとしての活用、デバッグやテストの支援も可能です。

SERVICE MESH アーキテクチャ

マイクロサービス間通信の制御で
多様な機能を担うサービスメッシュ

通信に関連する機能としては、タイムアウトの管理といったベーシックな機能に加え、リクエストの流量や同時接続数などの制御機能を標準機能として提供。リクエストが正常に届いているかどうかチェックし、不具合の発生したPODをサービスプールから外した上で、不具合が解消した後に再配置するといった対応を自動的に行ったり、特定のPODへのリクエスト集中を回避することも可能です。すべてのリクエストがEnvoyを経由するため、データを蓄積した上で、モニタリングツールのPrometheus、可視化ツールのGrafanaを組み合わせて監視するといったこともできます。

CI/CDに関わる機能では、カナリアリリースの場合、httpヘッダーに入っているユーザー情報によってルートを変更するといった高度な機能も持っていますし、A/Bデプロイなども簡単に行うことができます。

デバッグやテストの支援で有用になるのが分散トレースの機能です。リクエストに対してIDを割り振り、IDごとに追跡してリクエストとレスポンスの状況を見られるもので、Istioが標準で採用しているJaegerと言うトレーサーでは、サービスのレスポンスタイムの時系列分布を見るだけでなく、一つ一つのリクエストレスポンスを分解し、確認することができます。

WITH ISTIO

Istioでは、分散トレーシングのインターフェイスとして、複数の言語、複数のトレーサーに対応したベンダーニュートラルなOpenTracingを採用。Envoyを経由したリクエストを、自動的にトレースの対象とすることができます。その他、分散リモートデバッガであるSquash、ローカルに書いた変更をPODに反映するTelepresence、通信レイヤーに意図的にフォルト、ディレイを発生させることで異常系のテストを可能にするCHAOS ENGINEERING、Envoyが横取りするトラフィックを分岐利用して本番系に影響のない形でのテストを可能にするDARK LAUNCHESなども利便性の高いツールでしょう。

なお、Istioは、OpenShiftに正式サポートされることが決定しており、現在はTechnology Previewのステータスで提供されています。Istio だけでなく、とJaeger、Kiali、Prometheus、Grafanaを含めてOpenShift Service Meshとして提供予定です。このうちKialiは、RedHatがメインで開発しているもので、サービスのトポロジーを可視化し、ノードごとの詳細情報の確認、Istioの設定の確認が可能となります。事前にチュートリアルなども用意していますので、ご活用いただければと思います。

OPENSHIFT SERVICE MESH

須江信洋

第2回 Red Hat on Cloud Day イベントレポート