Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

jyoshise
August 02, 2018

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

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

jyoshise

August 02, 2018
Tweet

More Decks by jyoshise

Other Decks in Technology

Transcript

  1. 吉瀬 淳一 (@jyoshise)と申します • Hewlett Packard Enterpriseで働いています • プロフェッショナルサービスの人です •

    WW所属なのでいろんな国の仕事をしています • 特に製品の縛りはないです
  2. 想定オーディエンス • コンテナプラットフォームの導入を検討している。 • アプリケーション開発/インフラ運用を効率化したいから • ビジネス/自社サービス/社内ITにアジリティとスケーラビリティがほしい から • ボスに言われたから

    • なんとなく流行っていて面白そうだから • 今やっとくと転職に有利そうだから • コンテナ技術について、多少は調べたり試したり、実際に活用し たりしている。 • Docker • Kubernetes • ベンダーはそれぞれ我田引水なこと言うので実際 なにが正解なのかはよくわからない。とはいえ フルOSSで自力でゼロから組むのは無理。
  3. このセッションでの「エンタープライズコン テナプラットフォーム」って • Dockerイメージがクラスタ上にデプロイできる • コンテナワークロードがスケールできる • アプリケーションサービスを管理し公開する機能がある • アプリケーションルーティング

    • ロードバランサー • サービスディスカバリ • セルフヒーリング機能がある • エンタープライズグレードである • プロダクションレディな高可用性クラスタ • 商用サポート
  4. PaaS/FaaSもコンテナプラットフォームの 一種じゃね?という話 • PaaSやFaaSは、中でコンテナを使っ ていたとしても、利用者がコンテナ を意識するものではない • コンテナを意識するのは「PaaSを作 る人」 •

    いずれは同じゴールに到達するのだ ろうが今回の対象からは外します。 Cloud FoundryとKubernetesのカンケイにつ いては@ITに寄稿したのでぜひ読んでやって ください。 http://www.atmarkit.co.jp/ait/articles/1 807/18/news011.html
  5. エンタープライズのDevとOpsを考えると、コ ンテナは「ちょうどいい」 Dev: • 環境依存からの解放 • ポータビリティ DevOps: • テスト済みコンテナイメー

    ジでのプロモーション • 宣言的なサービス定義 Ops: • スケーラビリティ • リソースの有効活用 • セルフヒーリング
  6. Kubernetes: Picking the Right Solution • Kubernetesの公式docsに”Picking the Right Solution”という章があり、

    Kubernetes Certifiedなデプロイメントの 選択肢が一覧になっています。 • https://kubernetes.io/docs/setup/pick- right-solution/ • しかし・・・
  7. まず、ざっくり分類してみる (商用サポートのあるもの) マネージド プライベート プロプラ Kubernetes aaS Kubernetesベース k8s以外 GKE

    Azure Kubernetes Service • IBM • Oracle • Red Hat • Pivotal • etc DC/OS ピュアk8s Distro系 大いなる なにかの 一部 マルチ クラスタ系 IBM Cloud Private 独自強化 発展系 Docker
  8. マネージドCaaS(プロプラ) • Amazon ECS • コンテナレジストリ、ロードバランサー、認 証、監視、ネットワークなどはAWSの各サー ビスと密接に連携 • AWS

    Fargateの利用によりクラスタ管理も不 要なフルマネージドCaaSになる • AWSのみの利用に限って言えばいまだ最強 のCaaS ※個人の感想です プロプラ
  9. ピュアなKubernetesディストリビューション • アップストリームのKubernetesそのものに、 ライフサイクルマネジメント(インストー ラー)がついている • マニュアル通りにインストールすれば、エン タープライズグレードのKubernetesクラスタ が出来上がる •

    Canonical’s Distribution of Kubernetes • アップストリームファースト+エンタープライズ サポート(Ubuntuらしさ) • SUSE CaaS Platform • MicroOSとYaSTでライフサイクル管理 • K8sの上でCloud Foundryもサポート ピュアk8s Distro系
  10. Kubernetesをコアに独自強化したもの • Red Hat OpenShift Container Platform • コンテナオーケストレーションのコアとし てKubernetesを採用したRed

    Hatによるエン タープライズプロダクト • アップストリームはOpenShift Origin • アプリケーションのビルド(S2I/Jenkins)、 デプロイ管理、SDN、コンテナレジストリな ど、エンタープライズアプリケーション基 盤として必要な機能をKubernetes周辺に実 装 • 充実のドキュメントとナレッジベースで エンタープライズに優しい 独自強化 発展系
  11. 大いなるなにかの一部としてのKubernetes • Pivotal Container Service(PKS) • Cloud Foundry BOSHによるライフサイクルマ ネジメント

    • Pivotal Cloud Foundryユーザーにとっては有 力な選択肢 • Mesosphere DC/OS • Apache Mesosによる分散クラスタ。ビッグ データ系のサービスカタログが充実 • Kubernetes DC/OS 大いなる なにかの 一部 IBM Cloud Private
  12. 特にマルチクラスタ管理を意識したもの • Rancher • RancherのKubernetes(RKE)とそれ以外の Kubernetesを統合管理 • 共通のアプリケーションカタログから複 数クラスタにデプロイ •

    Tectonic • Multi-cluster registry, Multi-cluster RBACの実装(alpha) • CoreOSがRed Hatに買収されたので OpenShiftに統合か? • Docker EE • Federated Application Managementを発 表 マルチ クラスタ系 Docker
  13. 考慮すべき点: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
  14. 考慮すべき点:CI/CD(ビルド) Source Code Build (Compile) Version Control (Repository) Build (Docker)

    Container Image Artifact (Binary) Test • ここは普通のCI • Jenkins • Circle CI • Travis • Bamboo • etc
  15. 考慮すべき点: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)という機能があ る • もちろん出来合いのサービ ス/機能には制約がある • 対応言語/フレームワークな ど
  16. 考慮すべき点:CI/CD(マルチステージ) Container Image Container Registry Deploy (Test) Container Registry Deploy

    (Staging) Container Registry Deploy (Prod) • それぞれのステージにコ ンテナレジストリが必要 か • ステージごとにクラスタ を分けるか、データセン ター(クラウド)を分け るか • コンテナイメージに改ざ んがないことを保証でき るか • Docker Trusted Registry (TUF/Notary)
  17. 考慮すべき点: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パイプラインにどう組み 込むか
  18. 考慮すべき点:ネットワーク要件 • 既存のインフラ(ベアメタル/仮想マシン)とコンテナネットワーク の相互接続 • システムごとのテナント分離、ポリシー適用 • アクセスルーティング、サービスメッシュ • KubernetesではCNIプラグインが利用できるが

    各Distributionのデフォルトとサポートする 実装に注意 • CDKはCalico/flannel/Canal • OpenShiftはOpenShift SDN(OpenVSwitch) • パブリッククラウドでは各クラウドの 仮想ネットワークを利用 • SDN製品(プロプラ)とのインテグレーションも検討 • 今後Istioなどがサポートされた際に拡張できるか
  19. 考慮すべき点:ネットワーク要件 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
  20. 考慮すべき点:特殊なワークロード • 例えば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
  21. 考慮すべき点:特殊なワークロード • 例えば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/
  22. その他考慮すべき点 • パーシステンス • サポートされるVolume Pluginとパフォーマンス • SDS製品とのインテグレーションも検討 • 外部サービス

    • DB、機械学習、メッセージングなどの外部サービスとの連携 • 認証/認可 • 外部認証プロバイダとの統合、複数クラスタでのRBACの管理 • セキュリティ/パッチ • ホストレベルとコンテナレベルでのセキュリティ • コンテナイメージの監査 • パッチの適用手段
  23. 大きな分かれ目 • マネージドかプライベートか • 外部サービスとの連携、オンプレに置かなければならない理由、など • コンテナオーケストレーション以外のサービスの必要有無 • コンテナ化できない分散サービス、Cloud Foundryアプリケーションな

    ど • 現時点で完成度の高いソリューション(OpenShift)か、ピュア なKubernetesか • OpenShift流のDevOpsに乗るか、Kubernetesエコシステムから必要な パーツをそろえるか • Kubernetesエコシステムはまだ急速に発展している。今後の機能拡張 に追従できるか
  24. 提案例 GKE • まずはKubernetesに慣れ親しむところから • コンテナベースでのアプリ開発とインフラ運用でな にができるか検証したい • エンタープライズ基盤として万全なサポートが必須 •

    CI/CD,DevOpsに関するナレッジがないので適用でき るベストプラクティスが必要 • IaaSはオンプレとパブリッククラウドを併用 • クラウドとしてAWS以外の利用予定はない • DBなどのバックエンドサービスはAWSのマネージド サービスを最大限に利用している
  25. 提案例 • TensorflowなどのGPUワークロードをコンテナで管 理したい • ディープラーニングの学習データサービスも同じク ラスタ上に持ちたい • 将来の拡張のためにできるだけピュアなKubernetes がよい

    • 既存インフラとの接続/マルチテナンシーのため SDN/SDSのインテグレーションが必要 DC/OS +SDS/SDN • どうしてもWindowsアプリケーションをコンテナで 動かしたい