Slide 1

Slide 1 text

エンタープライズ コンテナプラットフォーム どれがええねん Cloud Native Days Tokyo 2018 吉瀬 淳一 (@jyoshise)

Slide 2

Slide 2 text

吉瀬 淳一 (@jyoshise)と申します • Hewlett Packard Enterpriseで働いています • プロフェッショナルサービスの人です • WW所属なのでいろんな国の仕事をしています • 特に製品の縛りはないです

Slide 3

Slide 3 text

今日話したいこと • エンタープライズコンテナプラットフォームにはどんなものが あるか • プラットフォームを選ぶうえでどんなことを気にしているか ※本資料および発言内容は業務上の経験・知識に基づいていますが、個人 の見解であり、所属する組織の公式見解ではありません。

Slide 4

Slide 4 text

想定オーディエンス • コンテナプラットフォームの導入を検討している。 • アプリケーション開発/インフラ運用を効率化したいから • ビジネス/自社サービス/社内ITにアジリティとスケーラビリティがほしい から • ボスに言われたから • なんとなく流行っていて面白そうだから • 今やっとくと転職に有利そうだから • コンテナ技術について、多少は調べたり試したり、実際に活用し たりしている。 • Docker • Kubernetes • ベンダーはそれぞれ我田引水なこと言うので実際 なにが正解なのかはよくわからない。とはいえ フルOSSで自力でゼロから組むのは無理。

Slide 5

Slide 5 text

このセッションでの「エンタープライズコン テナプラットフォーム」って • Dockerイメージがクラスタ上にデプロイできる • コンテナワークロードがスケールできる • アプリケーションサービスを管理し公開する機能がある • アプリケーションルーティング • ロードバランサー • サービスディスカバリ • セルフヒーリング機能がある • エンタープライズグレードである • プロダクションレディな高可用性クラスタ • 商用サポート

Slide 6

Slide 6 text

PaaS/FaaSもコンテナプラットフォームの 一種じゃね?という話 • PaaSやFaaSは、中でコンテナを使っ ていたとしても、利用者がコンテナ を意識するものではない • コンテナを意識するのは「PaaSを作 る人」 • いずれは同じゴールに到達するのだ ろうが今回の対象からは外します。 Cloud FoundryとKubernetesのカンケイにつ いては@ITに寄稿したのでぜひ読んでやって ください。 http://www.atmarkit.co.jp/ait/articles/1 807/18/news011.html

Slide 7

Slide 7 text

そもそも「コンテナプラットフォーム」であ る必要があるのか • アプリケーション開発者は、究極的にはアプリケーションコー ドだけを書いていたい • サーバーもコンテナもランタイムもバックエンドサービスのイ ンスタンスも意識したくない • だったらPaaSとかServerlessとかのほうがよいのではないか

Slide 8

Slide 8 text

エンタープライズのDevとOpsを考えると、コ ンテナは「ちょうどいい」 Dev: • 環境依存からの解放 • ポータビリティ DevOps: • テスト済みコンテナイメー ジでのプロモーション • 宣言的なサービス定義 Ops: • スケーラビリティ • リソースの有効活用 • セルフヒーリング

Slide 9

Slide 9 text

まず、ざっくり分類してみる (商用サポートのあるもの) マネージド プライベート

Slide 10

Slide 10 text

まず、ざっくり分類してみる (商用サポートのあるもの) マネージド プライベート プロプラ Kubernetes aaS GKE Azure Kubernetes Service • IBM • Oracle • Red Hat • Pivotal • etc

Slide 11

Slide 11 text

まず、ざっくり分類してみる (商用サポートのあるもの) マネージド プライベート プロプラ Kubernetes aaS Kubernetesベース k8s以外 GKE Azure Kubernetes Service • IBM • Oracle • Red Hat • Pivotal • etc DC/OS

Slide 12

Slide 12 text

まず、ざっくり分類してみる (商用サポートのあるもの) マネージド プライベート プロプラ Kubernetes aaS Kubernetesベース k8s以外 GKE Azure Kubernetes Service あとはこのへん どうなのよって 話ですが DC/OS

Slide 13

Slide 13 text

Kubernetes: Picking the Right Solution • Kubernetesの公式docsに”Picking the Right Solution”という章があり、 Kubernetes Certifiedなデプロイメントの 選択肢が一覧になっています。 • https://kubernetes.io/docs/setup/pick- right-solution/ • しかし・・・

Slide 14

Slide 14 text

Kubernetes: Picking the Right Solution

Slide 15

Slide 15 text

まず、ざっくり分類してみる (商用サポートのあるもの) マネージド プライベート プロプラ Kubernetes aaS Kubernetesベース k8s以外 GKE Azure Kubernetes Service • IBM • Oracle • Red Hat • Pivotal • etc DC/OS ピュアk8s Distro系 大いなる なにかの 一部 マルチ クラスタ系 IBM Cloud Private 独自強化 発展系 Docker

Slide 16

Slide 16 text

マネージドCaaS(プロプラ) • Amazon ECS • コンテナレジストリ、ロードバランサー、認 証、監視、ネットワークなどはAWSの各サー ビスと密接に連携 • AWS Fargateの利用によりクラスタ管理も不 要なフルマネージドCaaSになる • AWSのみの利用に限って言えばいまだ最強 のCaaS ※個人の感想です プロプラ

Slide 17

Slide 17 text

マネージドKaaS(Kubernetes aaS) • それぞれ中身は普通のKubernetes • Master管理は不要だがクラスタ管理は 必要 • 各クラウドが提供するKubernetes以外 のサービスとの連携で違いが出る Kubernetes aaS GKE Azure Kubernetes Service • IBM • Oracle • Red Hat • Pivotal • etc

Slide 18

Slide 18 text

ピュアなKubernetesディストリビューション • アップストリームのKubernetesそのものに、 ライフサイクルマネジメント(インストー ラー)がついている • マニュアル通りにインストールすれば、エン タープライズグレードのKubernetesクラスタ が出来上がる • Canonical’s Distribution of Kubernetes • アップストリームファースト+エンタープライズ サポート(Ubuntuらしさ) • SUSE CaaS Platform • MicroOSとYaSTでライフサイクル管理 • K8sの上でCloud Foundryもサポート ピュアk8s Distro系

Slide 19

Slide 19 text

Kubernetesをコアに独自強化したもの • Red Hat OpenShift Container Platform • コンテナオーケストレーションのコアとし てKubernetesを採用したRed Hatによるエン タープライズプロダクト • アップストリームはOpenShift Origin • アプリケーションのビルド(S2I/Jenkins)、 デプロイ管理、SDN、コンテナレジストリな ど、エンタープライズアプリケーション基 盤として必要な機能をKubernetes周辺に実 装 • 充実のドキュメントとナレッジベースで エンタープライズに優しい 独自強化 発展系

Slide 20

Slide 20 text

大いなるなにかの一部としてのKubernetes • Pivotal Container Service(PKS) • Cloud Foundry BOSHによるライフサイクルマ ネジメント • Pivotal Cloud Foundryユーザーにとっては有 力な選択肢 • Mesosphere DC/OS • Apache Mesosによる分散クラスタ。ビッグ データ系のサービスカタログが充実 • Kubernetes DC/OS 大いなる なにかの 一部 IBM Cloud Private

Slide 21

Slide 21 text

特にマルチクラスタ管理を意識したもの • Rancher • RancherのKubernetes(RKE)とそれ以外の Kubernetesを統合管理 • 共通のアプリケーションカタログから複 数クラスタにデプロイ • Tectonic • Multi-cluster registry, Multi-cluster RBACの実装(alpha) • CoreOSがRed Hatに買収されたので OpenShiftに統合か? • Docker EE • Federated Application Managementを発 表 マルチ クラスタ系 Docker

Slide 22

Slide 22 text

考慮すべき点: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

Slide 23

Slide 23 text

考慮すべき点:CI/CD(ビルド) Source Code Build (Compile) Version Control (Repository) Build (Docker) Container Image Artifact (Binary) Test • ここは普通のCI • Jenkins • Circle CI • Travis • Bamboo • etc

Slide 24

Slide 24 text

考慮すべき点: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)という機能があ る • もちろん出来合いのサービ ス/機能には制約がある • 対応言語/フレームワークな ど

Slide 25

Slide 25 text

考慮すべき点:CI/CD(マルチステージ) Container Image Container Registry Deploy (Test) Container Registry Deploy (Staging) Container Registry Deploy (Prod) • それぞれのステージにコ ンテナレジストリが必要 か • ステージごとにクラスタ を分けるか、データセン ター(クラウド)を分け るか • コンテナイメージに改ざ んがないことを保証でき るか • Docker Trusted Registry (TUF/Notary)

Slide 26

Slide 26 text

考慮すべき点: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パイプラインにどう組み 込むか

Slide 27

Slide 27 text

考慮すべき点:ネットワーク要件 • 既存のインフラ(ベアメタル/仮想マシン)とコンテナネットワーク の相互接続 • システムごとのテナント分離、ポリシー適用 • アクセスルーティング、サービスメッシュ • KubernetesではCNIプラグインが利用できるが 各Distributionのデフォルトとサポートする 実装に注意 • CDKはCalico/flannel/Canal • OpenShiftはOpenShift SDN(OpenVSwitch) • パブリッククラウドでは各クラウドの 仮想ネットワークを利用 • SDN製品(プロプラ)とのインテグレーションも検討 • 今後Istioなどがサポートされた際に拡張できるか

Slide 28

Slide 28 text

考慮すべき点:ネットワーク要件 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

Slide 29

Slide 29 text

考慮すべき点:特殊なワークロード • 例えば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

Slide 30

Slide 30 text

考慮すべき点:特殊なワークロード • 例えば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/

Slide 31

Slide 31 text

その他考慮すべき点 • パーシステンス • サポートされるVolume Pluginとパフォーマンス • SDS製品とのインテグレーションも検討 • 外部サービス • DB、機械学習、メッセージングなどの外部サービスとの連携 • 認証/認可 • 外部認証プロバイダとの統合、複数クラスタでのRBACの管理 • セキュリティ/パッチ • ホストレベルとコンテナレベルでのセキュリティ • コンテナイメージの監査 • パッチの適用手段

Slide 32

Slide 32 text

で、どれがええねん

Slide 33

Slide 33 text

大きな分かれ目 • マネージドかプライベートか • 外部サービスとの連携、オンプレに置かなければならない理由、など • コンテナオーケストレーション以外のサービスの必要有無 • コンテナ化できない分散サービス、Cloud Foundryアプリケーションな ど • 現時点で完成度の高いソリューション(OpenShift)か、ピュア なKubernetesか • OpenShift流のDevOpsに乗るか、Kubernetesエコシステムから必要な パーツをそろえるか • Kubernetesエコシステムはまだ急速に発展している。今後の機能拡張 に追従できるか

Slide 34

Slide 34 text

提案例 GKE • まずはKubernetesに慣れ親しむところから • コンテナベースでのアプリ開発とインフラ運用でな にができるか検証したい • エンタープライズ基盤として万全なサポートが必須 • CI/CD,DevOpsに関するナレッジがないので適用でき るベストプラクティスが必要 • IaaSはオンプレとパブリッククラウドを併用 • クラウドとしてAWS以外の利用予定はない • DBなどのバックエンドサービスはAWSのマネージド サービスを最大限に利用している

Slide 35

Slide 35 text

提案例 • TensorflowなどのGPUワークロードをコンテナで管 理したい • ディープラーニングの学習データサービスも同じク ラスタ上に持ちたい • 将来の拡張のためにできるだけピュアなKubernetes がよい • 既存インフラとの接続/マルチテナンシーのため SDN/SDSのインテグレーションが必要 DC/OS +SDS/SDN • どうしてもWindowsアプリケーションをコンテナで 動かしたい

Slide 36

Slide 36 text

特にオチはないのですが • プラットフォーム検討の参考になれば幸いです • いちおう私たちプロなので、ご相談ください! • あとWe are hiring!