エンタープライズコンテナプラットフォーム、どれがええねん

Cloud Native Days Tokyo 2018での発表資料です。
・エンタープライズコンテナプラットフォームにはどんなものがあるか
・プラットフォームを選ぶうえでどんなことを気にしているか

Transcript

1. エンタープライズ コンテナプラットフォーム どれがええねん Cloud Native Days Tokyo 2018 吉瀬 淳一 (@jyoshise)
2. 吉瀬 淳一 (@jyoshise)と申します • Hewlett Packard Enterpriseで働いています • プロフェッショナルサービスの人です • WW所属なのでいろんな国の仕事をしています • 特に製品の縛りはないです
3. 今日話したいこと • エンタープライズコンテナプラットフォームにはどんなものが あるか • プラットフォームを選ぶうえでどんなことを気にしているか ※本資料および発言内容は業務上の経験・知識に基づいていますが、個人 の見解であり、所属する組織の公式見解ではありません。
4. 想定オーディエンス • コンテナプラットフォームの導入を検討している。 • アプリケーション開発/インフラ運用を効率化したいから • ビジネス/自社サービス/社内ITにアジリティとスケーラビリティがほしい から • ボスに言われたから • なんとなく流行っていて面白そうだから • 今やっとくと転職に有利そうだから • コンテナ技術について、多少は調べたり試したり、実際に活用し たりしている。 • Docker • Kubernetes • ベンダーはそれぞれ我田引水なこと言うので実際 なにが正解なのかはよくわからない。とはいえ フルOSSで自力でゼロから組むのは無理。
5. このセッションでの「エンタープライズコン テナプラットフォーム」って • Dockerイメージがクラスタ上にデプロイできる • コンテナワークロードがスケールできる • アプリケーションサービスを管理し公開する機能がある • アプリケーションルーティング • ロードバランサー • サービスディスカバリ • セルフヒーリング機能がある • エンタープライズグレードである • プロダクションレディな高可用性クラスタ • 商用サポート
6. PaaS/FaaSもコンテナプラットフォームの 一種じゃね？という話 • PaaSやFaaSは、中でコンテナを使っ ていたとしても、利用者がコンテナ を意識するものではない • コンテナを意識するのは「PaaSを作 る人」 • いずれは同じゴールに到達するのだ ろうが今回の対象からは外します。 Cloud FoundryとKubernetesのカンケイにつ いては@ITに寄稿したのでぜひ読んでやって ください。 http://www.atmarkit.co.jp/ait/articles/1 807/18/news011.html
7. そもそも「コンテナプラットフォーム」であ る必要があるのか • アプリケーション開発者は、究極的にはアプリケーションコー ドだけを書いていたい • サーバーもコンテナもランタイムもバックエンドサービスのイ ンスタンスも意識したくない • だったらPaaSとかServerlessとかのほうがよいのではないか
8. エンタープライズのDevとOpsを考えると、コ ンテナは「ちょうどいい」 Dev: • 環境依存からの解放 • ポータビリティ DevOps: • テスト済みコンテナイメー ジでのプロモーション • 宣言的なサービス定義 Ops: • スケーラビリティ • リソースの有効活用 • セルフヒーリング
9. まず、ざっくり分類してみる (商用サポートのあるもの) マネージド プライベート
10. まず、ざっくり分類してみる (商用サポートのあるもの) マネージド プライベート プロプラ Kubernetes aaS GKE Azure Kubernetes Service • IBM • Oracle • Red Hat • Pivotal • etc
11. まず、ざっくり分類してみる (商用サポートのあるもの) マネージド プライベート プロプラ Kubernetes aaS Kubernetesベース k8s以外 GKE Azure Kubernetes Service • IBM • Oracle • Red Hat • Pivotal • etc DC/OS
12. まず、ざっくり分類してみる (商用サポートのあるもの) マネージド プライベート プロプラ Kubernetes aaS Kubernetesベース k8s以外 GKE Azure Kubernetes Service あとはこのへん どうなのよって 話ですが DC/OS
13. Kubernetes: Picking the Right Solution • Kubernetesの公式docsに”Picking the Right Solution”という章があり、 Kubernetes Certifiedなデプロイメントの 選択肢が一覧になっています。 • https://kubernetes.io/docs/setup/pick- right-solution/ • しかし・・・
14. Kubernetes: Picking the Right Solution
15. まず、ざっくり分類してみる (商用サポートのあるもの) マネージド プライベート プロプラ Kubernetes aaS Kubernetesベース k8s以外 GKE Azure Kubernetes Service • IBM • Oracle • Red Hat • Pivotal • etc DC/OS ピュアk8s Distro系 大いなる なにかの 一部 マルチ クラスタ系 IBM Cloud Private 独自強化 発展系 Docker
16. マネージドCaaS(プロプラ） • Amazon ECS • コンテナレジストリ、ロードバランサー、認 証、監視、ネットワークなどはAWSの各サー ビスと密接に連携 • AWS Fargateの利用によりクラスタ管理も不 要なフルマネージドCaaSになる • AWSのみの利用に限って言えばいまだ最強 のCaaS ※個人の感想です プロプラ
17. マネージドKaaS(Kubernetes aaS) • それぞれ中身は普通のKubernetes • Master管理は不要だがクラスタ管理は 必要 • 各クラウドが提供するKubernetes以外 のサービスとの連携で違いが出る Kubernetes aaS GKE Azure Kubernetes Service • IBM • Oracle • Red Hat • Pivotal • etc
18. ピュアなKubernetesディストリビューション • アップストリームのKubernetesそのものに、 ライフサイクルマネジメント（インストー ラー）がついている • マニュアル通りにインストールすれば、エン タープライズグレードのKubernetesクラスタ が出来上がる • Canonical’s Distribution of Kubernetes • アップストリームファースト＋エンタープライズ サポート(Ubuntuらしさ) • SUSE CaaS Platform • MicroOSとYaSTでライフサイクル管理 • K8sの上でCloud Foundryもサポート ピュアk8s Distro系
19. Kubernetesをコアに独自強化したもの • Red Hat OpenShift Container Platform • コンテナオーケストレーションのコアとし てKubernetesを採用したRed Hatによるエン タープライズプロダクト • アップストリームはOpenShift Origin • アプリケーションのビルド(S2I/Jenkins)、 デプロイ管理、SDN、コンテナレジストリな ど、エンタープライズアプリケーション基 盤として必要な機能をKubernetes周辺に実 装 • 充実のドキュメントとナレッジベースで エンタープライズに優しい 独自強化 発展系
20. 大いなるなにかの一部としてのKubernetes • Pivotal Container Service(PKS) • Cloud Foundry BOSHによるライフサイクルマ ネジメント • Pivotal Cloud Foundryユーザーにとっては有 力な選択肢 • Mesosphere DC/OS • Apache Mesosによる分散クラスタ。ビッグ データ系のサービスカタログが充実 • Kubernetes DC/OS 大いなる なにかの 一部 IBM Cloud Private
21. 特にマルチクラスタ管理を意識したもの • Rancher • RancherのKubernetes(RKE)とそれ以外の Kubernetesを統合管理 • 共通のアプリケーションカタログから複 数クラスタにデプロイ • Tectonic • Multi-cluster registry, Multi-cluster RBACの実装(alpha) • CoreOSがRed Hatに買収されたので OpenShiftに統合か？ • Docker EE • Federated Application Managementを発 表 マルチ クラスタ系 Docker
22. 考慮すべき点：CI/CD Source Code Manifests Build (Compile) Version Control (Repository) Build (Docker) Container Image Artifact (Binary) Test Container Registry Deploy (Test) Container Registry Deploy (Staging) Container Registry Deploy (Prod) Manifest Manifest Manifest
23. 考慮すべき点：CI/CD(ビルド) Source Code Build (Compile) Version Control (Repository) Build (Docker) Container Image Artifact (Binary) Test • ここは普通のCI • Jenkins • Circle CI • Travis • Bamboo • etc
24. 考慮すべき点：CI/CD(ビルド) Source Code Build (Compile) Version Control (Repository) Build (Docker) Container Image Artifact (Binary) Test • パブリッククラウドではこ こがサービスとして提供さ れている • AWS CodeBuild • Google Cloud Build • etc • OpenShiftにはSource to Image(S2I)という機能があ る • もちろん出来合いのサービ ス/機能には制約がある • 対応言語/フレームワークな ど
25. 考慮すべき点：CI/CD(マルチステージ) Container Image Container Registry Deploy (Test) Container Registry Deploy (Staging) Container Registry Deploy (Prod) • それぞれのステージにコ ンテナレジストリが必要 か • ステージごとにクラスタ を分けるか、データセン ター（クラウド）を分け るか • コンテナイメージに改ざ んがないことを保証でき るか • Docker Trusted Registry (TUF/Notary)
26. 考慮すべき点：CI/CD(マルチステージ) Manifests Container Registry Deploy (Test) Container Registry Deploy (Staging) Container Registry Deploy (Prod) Manifest Manifest Manifest • いわゆるYAMLの壁問題 • それぞれのステージのデプロ イメントはスペックが異なる →それぞれにYAMLが必要 • 通常アプリケーションサービ スは単一のPodで構成されるわ けではない→マルチレイヤー のサービスをどう管理するか • Helm • Kustomize • CI/CDパイプラインにどう組み 込むか
27. 考慮すべき点：ネットワーク要件 • 既存のインフラ（ベアメタル/仮想マシン）とコンテナネットワーク の相互接続 • システムごとのテナント分離、ポリシー適用 • アクセスルーティング、サービスメッシュ • KubernetesではCNIプラグインが利用できるが 各Distributionのデフォルトとサポートする 実装に注意 • CDKはCalico/flannel/Canal • OpenShiftはOpenShift SDN(OpenVSwitch) • パブリッククラウドでは各クラウドの 仮想ネットワークを利用 • SDN製品（プロプラ）とのインテグレーションも検討 • 今後Istioなどがサポートされた際に拡張できるか
28. 考慮すべき点：ネットワーク要件 SDN製品のインテグレーション（例） Network Isolation Network Orchestration Network Isolation between Kubernetes namespaces Network configuration deployment would be automated with Kubenetes Scalable Network Highly scalable network control plane can respond to rapid provisioning Supportability Provide commercial supportability for connectivity of container Container Orchestrator HPE Infrastructure Bare metal / Virtual DCN Apollo for AI / DL Synergy for MC Benefit of Architecture SUSE CaaSP w/ DCN K8S 1.9 with DCN Development w/ Pointnext HIT Center of Excellence Integration w/ Synergy Step1 Step2 Step3 DL Series for DevOps * * • ベアメタル-仮想マシン-コンテナをまたがった仮 想ネットワーク • テナント分離 • トップダウンでのポリシーの適用 • etc
29. 考慮すべき点：特殊なワークロード • 例えばGPUとビッグデータを要求するディープラーニング • 現時点でGPUをサポートしている商用Kubernetesディストリ ビューションはない。Mesos/Marathonはサポートしている • パブリッククラウドの マネージドK8sではGPUが 使えるが、学習データは パブリッククラウドに 置けるか TensorFlow 1.0 Ubuntu16.04 Container image build automation Container Orchestration Platform GPU GPU GPU GPU Training Job Inference app Inference User Data Scientist GPU GPU GPU GPU GPU GPU GPU GPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU Distributed workers Training Data Model CUDA8.0 cuDNN v6 TensorFlow 1.0 Ubuntu16.04 TensorFlow 1.0 Ubuntu16.04 Training Job Inference app Other framework/version Training Code Application Code App Developer
30. 考慮すべき点：特殊なワークロード • 例えばGPUとビッグデータを要求するディープラーニング • 現時点でGPUをサポートしている商用Kubernetesディストリ ビューションはない。Mesos/Marathonはサポートしている • パブリッククラウドの マネージドK8sではGPUが 使えるが、学習データは パブリッククラウドに 置けるか 8/4追記： 現状Kubernetes(1.11現在)では、NVIDIA Device PluginによるGPUスケジューリングは”experimental support”となっています。 https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/ したがって、各社商用ディストリビューションにおいてもGPUの利用はTech Preview扱いであり、現時点 で正式サポート対象にはなっていません・・・というのがこの資料を書いた時点での認識だったのですが、 今週（7/31）リリースされたRed Hat OpenShift Container Platform 3.10ではDevice Plugin APIが正式 サポート(GA)となったようです。 https://blog.openshift.com/how-to-use-gpus-with-deviceplugin-in-openshift-3-10/ また、Canonical’s Distribution of KubernetesでもGPU-enabledなクラスタをデプロイするためのJuju charmsが用意されています。ただしこちらはPreview(AWS Only)というステータスのようです。 https://jujucharms.com/u/containers/canonical-kubernetes-nvidia/
31. その他考慮すべき点 • パーシステンス • サポートされるVolume Pluginとパフォーマンス • SDS製品とのインテグレーションも検討 • 外部サービス • DB、機械学習、メッセージングなどの外部サービスとの連携 • 認証/認可 • 外部認証プロバイダとの統合、複数クラスタでのRBACの管理 • セキュリティ/パッチ • ホストレベルとコンテナレベルでのセキュリティ • コンテナイメージの監査 • パッチの適用手段
32. で、どれがええねん
33. 大きな分かれ目 • マネージドかプライベートか • 外部サービスとの連携、オンプレに置かなければならない理由、など • コンテナオーケストレーション以外のサービスの必要有無 • コンテナ化できない分散サービス、Cloud Foundryアプリケーションな ど • 現時点で完成度の高いソリューション(OpenShift)か、ピュア なKubernetesか • OpenShift流のDevOpsに乗るか、Kubernetesエコシステムから必要な パーツをそろえるか • Kubernetesエコシステムはまだ急速に発展している。今後の機能拡張 に追従できるか
34. 提案例 GKE • まずはKubernetesに慣れ親しむところから • コンテナベースでのアプリ開発とインフラ運用でな にができるか検証したい • エンタープライズ基盤として万全なサポートが必須 • CI/CD,DevOpsに関するナレッジがないので適用でき るベストプラクティスが必要 • IaaSはオンプレとパブリッククラウドを併用 • クラウドとしてAWS以外の利用予定はない • DBなどのバックエンドサービスはAWSのマネージド サービスを最大限に利用している
35. 提案例 • TensorflowなどのGPUワークロードをコンテナで管 理したい • ディープラーニングの学習データサービスも同じク ラスタ上に持ちたい • 将来の拡張のためにできるだけピュアなKubernetes がよい • 既存インフラとの接続/マルチテナンシーのため SDN/SDSのインテグレーションが必要 DC/OS +SDS/SDN • どうしてもWindowsアプリケーションをコンテナで 動かしたい
36. 特にオチはないのですが • プラットフォーム検討の参考になれば幸いです • いちおう私たちプロなので、ご相談ください！ • あとWe are hiring!