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

「VM 時代の開発とKubernetes による Cloud Native な開発のこれから」Infra Study Meetup #2 / infrastudy2-k8s

「VM 時代の開発とKubernetes による Cloud Native な開発のこれから」Infra Study Meetup #2 / infrastudy2-k8s

「VM 時代の開発とKubernetes による Cloud Native な開発のこれから」
Infra Study Meetup #2

More Decks by Masaya Aoyama (@amsy810)

Other Decks in Technology

Transcript

  1. Masaya Aoyama
    CyberAgent
    ʮVM ࣌୅ͷ։ൃʯͱ
    ʮKubernetes ʹΑΔ Cloud Native ͳ։ൃʯͷ
    ͜Ε͔Β
    Infra Study Meetup #2
    amsy810 @amsy810

    View full-size slide

  2. - Co-chair
    ੨ࢁ ਅ໵
    + CREATIONLINE / DENSO - 技術アドバイザ
    + SAKURA Internet Research Center – 客員研究員
    - Organizer
    - KaaS Product Owner - Publications
    Twitter: @amsy810

    View full-size slide

  3. サイバーエージェントには、特定の分野に抜きん出た知識とスキルを持ち、その領域の第一人者とし
    て実績を上げているエンジニアに、新たな活躍の場を提供するとともに、各専門領域において、その
    分野の発展のための貢献および、サイバーエージェントグループに還元することを目的とした
    「Developer Experts制度」があります。
    「Developer Experts」の選出は、これまでの実績に基づいて、サイバーエージェントが注力する技術
    領域から5名を選出しました。任命されたメンバーは、担当領域における、その技術や使われ方などに
    ついて中立的な立場で発信することで、各担当領域の活性化に貢献することを目指します。
    「Developer Experts」の5名には、大きく以下の3つの役割が任されています。
    • 各専門領域において高い専門性を身につけ、その発展に貢献すること。
    • 対外活動(登壇・コミュニティ活動・執筆・情報発信)を通して、各専門領域の発展に貢献するこ
    と。
    • 各専門領域におけるサイバーエージェント全体の旗振り役として、管轄や事業部の垣根を超えて、
    担当領域の相談を受けたりサポートすること。
    これらの活動を支援するため、会社からは国内外を含む活動費のサポートを行い、全面的にバック
    アップしていきます。
    技術支援制度 Developer Experts制度 -
    https://www.cyberagent.co.jp/techinfo/info/detail/id=23823

    View full-size slide

  4. Cloud Native Meetup Tokyo と Forkwell さん
    Cloud Native Meetup Tokyo #2 ( 2018/6/1 )から
    実は何度かスポンサーをしていただいてます。

    View full-size slide

  5. Masaya Aoyama
    CyberAgent
    ʮVM ࣌୅ͷ։ൃʯͱ
    ʮKubernetes ʹΑΔ Cloud Native ͳ։ൃʯͷ
    ͜Ε͔Β
    Infra Study Meetup #2
    amsy810 @amsy810

    View full-size slide

  6. ͜͜Ͱ͍͏ VM ࣌୅ͱ͸ʁ

    View full-size slide

  7. 物理マシン時代 -2000年 (※ 年代は立場や会社によって異なります)
    • 数台のサーバ上でアプリケーションを動作
    • 台数もそこまで多くはなく、1台1台をペット(Pet)として扱う
    物理マシン
    時代
    仮想マシン
    時代 (1)
    仮想マシン
    時代 (2)
    CloudNative
    時代

    View full-size slide

  8. 仮想マシン時代(1) 2001-2009年
    • 物理マシンの代替 としてVMを使う
    • このときもVMはまだペットとして扱われている
    • 集約率をあげて高効率化をすることが目的
    • サーバのメニーコア化と仮想化技術の普及
    • VMの代替としてのコンテナ技術自体は存在(いわゆる System Container)
    物理マシン
    時代
    仮想マシン
    時代 (1)
    仮想マシン
    時代 (2)
    CloudNative
    時代
    2003 2007
    2001 (ESX)
    2006 (EC2/S3)

    View full-size slide

  9. 仮想マシン時代(2)≒ Cloud 時代 2010-2015年
    • Webサービスの普及によりスケーラブルなシステム設計
    • クラウドが普及し、無尽蔵なリソースを利用可能に
    • データベースなどのマネージドサービスも拡充
    • 安定的に大規模インフラを管理するための技術も普及
    • Immutable Infrastructure
    • Infrastructure as Code
    • 合わせて DevOps の考え方も普及
    物理マシン
    時代
    仮想マシン
    時代 (1)
    仮想マシン
    時代 (2)
    CloudNative
    時代

    View full-size slide

  10. Cloud Native 時代 2016年-現在
    • 仮想マシン時代(2) はインフラ側から寄っていった方法
    • アプリ側とも歩幅をあわせた方法論 = Cloud Nativeのはじまり
    • IaC, Immutable Infrastructure, Cattle 化なども継承
    • アプリケーションを実行するために最適なインフラ
    • 開発したものを「即座に」「安定的に」提供する(ビジネス優位性のためにも)
    物理マシン
    時代
    仮想マシン
    時代 (1)
    仮想マシン
    時代 (2)
    CloudNative
    時代

    View full-size slide

  11. Cloud Native 時代 2016年-現在
    • アプリケーションを実行するために最適なインフラの最適解のひとつ
    • Docker
    • Kubernetes
    • Serverless
    • PaaS
    • (VM)
    • etc
    物理マシン
    時代
    仮想マシン
    時代 (1)
    仮想マシン
    時代 (2)
    CloudNative
    時代
    その他の選択肢も十分にありえる

    View full-size slide

  12. Cloud Native 時代 2016年-現在
    • アプリケーションを実行するために最適なインフラ
    • 開発したものを「即座に」「安定的に」提供する(ビジネス優位性のためにも)
    物理マシン
    時代
    仮想マシン
    時代 (1)
    仮想マシン
    時代 (2)
    CloudNative
    時代
    今でこそ CloudNative と名前がついているが
    パブリッククラウドもこうした思想で取り組んでいると思う
    こういった思想から生まれたもののひとつが Docker / Kubernetes

    View full-size slide

  13. Cloud Native 時代 2016年-現在
    • アプリケーションを実行するために最適なインフラの最適解のひとつ
    • Docker( Application Container )
    • 正しく動かすためにアプリケーションと動作環境のパッケージング
    • 開発者にとってのイメージのビルドの容易性
    • アプリケーション起動と同等の低オーバーヘッド
    • Kubernetes( Container Orchestrator )
    • アプリケーションの実行を第一に考えたときに
    どういうインフラを作るかを主軸に設計されたインフラ基盤
    物理マシン
    時代
    仮想マシン
    時代 (1)
    仮想マシン
    時代 (2)
    CloudNative
    時代
    Develper Experience の良さ
    Reconcilliation modelの洗練さ

    View full-size slide

  14. CNCF͕ݴ͏Cloud Nativeͱ͸ʁ

    View full-size slide

  15. Cloud Nativeとは?
    クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの
    近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能
    力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービ
    ス、イミュータブルインフラストラクチャ、および宣言型APIがあります。
    これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅
    牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測ど
    おりに行うことができます。
    Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育
    成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化
    し、これらのイノベーションを誰もが利用できるようにします。
    CNCF Cloud Native Defenition v1.0, CNCF, 2018-11-28
    (https://github.com/cncf/toc/blob/master/DEFINITION.md)

    View full-size slide

  16. Cloud Nativeとは?
    Cloud native technologies empower organizations to build and run scalable
    applications in modern, dynamic environments such as public, private, and hybrid
    clouds. Containers, service meshes, microservices, immutable infrastructure, and
    declarative APIs exemplify this approach.
    These techniques enable loosely coupled systems that are resilient, manageable,
    and observable. Combined with robust automation, they allow engineers to make
    high-impact changes frequently and predictably with minimal toil.
    The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by
    fostering and sustaining an ecosystem of open source, vendor-neutral projects. We
    democratize state-of-the-art patterns to make these innovations accessible for
    everyone.
    CNCF Cloud Native Defenition v1.0, CNCF, 2018-11-28
    (https://github.com/cncf/toc/blob/master/DEFINITION.md)
    • 疎結合なシステム
    • 復元力がある
    • 管理しやすい
    • 可観測である
    • 堅牢な自動化により、頻繁かつ期待通り
    に最小限の労力で大きな変更が可能
    OpenかつScalableなシステムを実現
    テクニカルに

    View full-size slide

  17. Cloud Nativeとは?
    クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの
    近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能
    力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービ
    ス、イミュータブルインフラストラクチャ、および宣言型APIがあります。
    これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅
    牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測ど
    おりに行うことができます。
    Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育
    成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化
    し、これらのイノベーションを誰もが利用できるようにします。
    CNCF Cloud Native Defenition v1.0, CNCF, 2018-11-28
    (https://github.com/cncf/toc/blob/master/DEFINITION.md)
    これにより、開発したものを「即座に」「安定的に」実行できます。
    前とは異なり、
    DevとOpsが一緒に考えた、アプリケーションの実行環境を、最適な形で利用します。
    CNCFはオープンソースを推奨します。
    ≒ 必須ではない( 個人の見解 )
    個人的な意訳的に

    View full-size slide

  18. Kubernetes Concept 101

    View full-size slide

  19. Kubernetes と「リソース」
    Google Borg をベースとした洗練された基盤
    • ローリングアップデート
    • オートスケール
    • ロードバランサとの⾃動連携(抽象化)
    様々なものを「リソース」として扱う
    リソースを記述したマニフェストを K8s に登録
    ReplicaSet リソースを登録

    View full-size slide

  20. 『X as a Service 基盤』としての Kubernetes
    Platform for Platform
    • Database as a Service on Kubernetes
    • Queue as a Service on Kubernetes
    • Serverless as a Service on Kubernetes
    • ML as a Service on Kubernetes
    presslabs/mysql-operator
    『障害時のクラスタ復旧』
    『バックアップなどの運用』
    を自動化(マネージド)

    View full-size slide

  21. 『X as a Service 基盤』としての Kubernetes
    Kubernetes は ⼩さなクラウド に近い
    Message Queue
    Key Value
    Store
    Document DB
    Relational DB
    Developer
    ステートフルなもの以外にも
    ML、Serverless、バッチJobなど
    様々なものを Kubernetes 上で提供する
    エコシステムが発達

    View full-size slide

  22. Ϋϥ΢υ؀ڥ ͱ Cloud Native

    View full-size slide

  23. クラウド環境 と Cloud Native
    • Kubernetesもクラウド環境相当の機能を持っている
    • コンテナなどを使わなければ Cloud Native ではないか?
    • 前述の Cloud Native を目指しさえすれば、それは Cloud Native(だと私は考える)
    • 逆に Kubernetes を従来的な使い方しかできない場合は、Cloud Native ではない
    RDS
    MySQLCluster CloudSQL
    EC2 Auto Scaling
    HPA Auto Scaling Group
    EC2 Auto Scaling
    Deployment Instance Template
    AMI
    Container Image Custom Image

    View full-size slide

  24. Managed Kubernetes on Public Cloud
    最近の環境は K8s on クラウド環境
    • Nested VM ならぬ Nested Cloud

    View full-size slide

  25. Kubernetes 導入の進め方
    • 純粋な Computing Workload のみを Kubernetes 上で実行
    • Deployment リソース(アプリケーションの実行)
    • Service リソース(ロードバランサとの連携)
    • クラウド環境と Kubernetes は適切に共存していくべき
    • 共存レベルは利用するクラウド環境により異なる
    • AWS, GCP, OpenStack, etc.
    Computing
    Computing

    View full-size slide

  26. VM࣌୅ͱͷൺֱ
    ΞϓϦέʔγϣϯͷ࣮ߦΛୈҰʹߟ͑ͨΠϯϑϥ
    ʢ̍ʣଈ࠲ʹ҆ఆͨ͠ϏϧυʙσϓϩΠΛ࣮ݱ͢ΔΠϝʔδԽ
    ʢ̎ʣΞϓϦέʔγϣϯ࣮ߦͷϕετϓϥΫςΟεͷίʔυԽ
    ʢ̏ʣΠϯϑϥͷந৅Խ

    View full-size slide

  27. Bootstrap & Orchestrate
    Terraform
    CloudFormation / Heat
    Configuration
    Chef / Ansible / Puppet / Salt
    Packer
    Deploy
    Jenkins / Capistrano
    パターン 1
    • Terraform で VM を起動
    • CAPS でセットアップ
    • Jenkins でアプリのデプロイ
    ・イメージビルド時間︓0 min
    ・デプロイ時間︓10 min〜60 min
    ・同⼀環境になることが保証されない
    ・複数のツールの習得が必要
    [VM] インフラのビルド〜デプロイまでの道のり

    View full-size slide

  28. [VM] インフラのビルド〜デプロイまでの道のり
    Bootstrap & Orchestrate
    Terraform
    CloudFormation / Heat
    Configuration
    Chef / Ansible / Puppet / Salt
    Packer
    Deploy
    Jenkins / Capistrano
    パターン 2
    • Packer で VM イメージのビルド
    • Terraform で VM を起動
    • Jenkins でアプリのデプロイ
    ・イメージビルド時間︓10 min - 30 min
    ・デプロイ時間︓5 min
    ・同⼀環境になることが保証される
    ・複数のツールの習得が必要

    View full-size slide

  29. [CloudNative] インフラのビルド〜デプロイまでの道のり
    Bootstrap & Orchestrate
    Kubernetes Manifests
    Configuration
    Dockerfile
    Kubernetes Manifests
    Deploy
    Kubernetes Manifests
    パターン 3
    • Dockerfile でイメージのビルド
    • K8s Manifest でコンテナを起動
    • ミドルウェア
    • アプリケーション
    • サービス間の接続性も管理
    ・イメージビルド時間︓1 min - 10 min
    ・デプロイ時間︓5 sec – 1 min
    ・同⼀環境になることが保証される
    ・少ない数のツールの習得で⼗分
    イメージ化がとても容易
    Dev 側が関わることができる

    View full-size slide

  30. [VM] アプリのビルド〜デプロイまでの道のり
    Code
    Repository
    S3 / etc
    CI - test, build
    VM
    CD - Deploy
    v1 v2 v3

    View full-size slide

  31. [CloudNative] アプリのビルド〜デプロイまでの道のり
    Code
    Repository
    Docker
    Registry
    CI - test, build
    Kubernetes
    CI - update manifests
    Manifest
    Repository CD - depoy
    v1 v2 v3
    v1 v2 v3
    GItOps の場合:
    アプリケーションの状態がコード化
    環境込みのアプリケーション

    View full-size slide

  32. [CloudNative] 開発用環境の準備のしやすさ
    Docker
    Registry
    Kubernetes
    Manifest
    Repository
    v1 v2 v3
    v1 v2 v3
    アーティファクトはコンテナとマニフェスト
    外部に依存する部分さえ用意すれば、手元でも再現可能
    DBなどもコンテナとして起動することが容易

    View full-size slide

  33. VM࣌୅ͱͷൺֱ
    ΞϓϦέʔγϣϯͷ࣮ߦΛୈҰʹߟ͑ͨΠϯϑϥ
    ʢ̍ʣଈ࠲ʹ҆ఆͨ͠ϏϧυʙσϓϩΠΛ࣮ݱ͢ΔΠϝʔδԽ
    ʢ̎ʣΞϓϦέʔγϣϯ࣮ߦͷϕετϓϥΫςΟεͷίʔυԽ
    ʢ̏ʣΠϯϑϥͷந৅Խ

    View full-size slide

  34. CAPS のコード化と Kubernetes のコード化の違い
    • CAPS や Terraform のコード化
    • あくまでも構築スクリプト的(宣言的記述のサポートと冪等性による再実行)
    • Cloud Formation や Instance Group などと組み合わせることで…
    • Kubernetesのコード化
    • アプリケーションをどう動かすかに主眼
    • 安定的に動かすためのベストプラクティス的設定郡
    • インフラ運用に関するベストプラクティスのコード化
    a

    View full-size slide

  35. [Kubernetes] アプリ実行のベストプラクティスのコード化
    spec:
    containers:
    - name: cart-app-container
    image: cart-app:v1.2.3
    env:
    - name: DB_HOST
    value: db.product
    readinessProbe:
    httpGet:
    path: /healthz
    resources:
    requests:
    cpu: 100m
    memory: 128Mi
    lifecycle:
    preStop: {...}
    postStart: {...}
    terminationGracePeriodSeconds: 30
    コンテナの停止処理に関する設定
    SIGTERM/SIGKILL による停止容易性の確保
    アプリケーションが前提となる実行宣言
    ヘルスチェック設定
    アプリケーションが動作するための
    リソースの割り当て
    アプリケーション実行時の
    ライフサイクルに関する設定
    環境変数による環境の切り分け

    View full-size slide

  36. VM࣌୅ͱͷൺֱ
    ΞϓϦέʔγϣϯͷ࣮ߦΛୈҰʹߟ͑ͨΠϯϑϥ
    ʢ̍ʣଈ࠲ʹ҆ఆͨ͠ϏϧυʙσϓϩΠΛ࣮ݱ͢ΔΠϝʔδԽ
    ʢ̎ʣΞϓϦέʔγϣϯ࣮ߦͷϕετϓϥΫςΟεͷίʔυԽ
    ʢ̏ʣΠϯϑϥͷந৅Խ

    View full-size slide

  37. [VM] ロードバランサの連携/IPアドレスの管理
    ロードバランサ連携
    • ⾃前スクリプト
    • 別ツール
    • ⼿動管理だったり
    IPアドレス管理
    • VM ごとに把握・管理し、Ansible / Chef などで構成管理を実⾏

    View full-size slide

  38. 起動したPod(コンテナ)には ラベル が付与されている
    Kubernetes や周辺エコシステムでは
    ラベルを元に様々な処理を⾏う
    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: sample-deployment
    spec:
    replicas: 3
    template:
    metadata:
    labels: {app: a}
    spec:
    containers:
    - name: app-container
    image: app:A
    app: a
    app: a
    app: a
    [Kubernetes] ロードバランサとの連携

    View full-size slide

  39. ⾃動的に LoadBalancer を作成し、⾃動的に連携を⾏う
    • コンテナやノードの追加時にも⾃動的にメンバ更新
    • ローリングアップデート時のメンバ管理
    開発者も管理が可能
    apiVersion: v1
    kind: Service
    metadata:
    name: sample-svc
    spec:
    type: LoadBalancer
    ports:
    - name: "http-port"
    protocol: "TCP"
    port: 8080
    targetPort: 80
    selector:
    app: a
    app: a
    app: a
    app: a
    LB app: a
    [Kubernetes] ロードバランサとの連携

    View full-size slide

  40. Kubernetes では IP Address を⼀切管理しない
    Kubernetes 内部の通信は
    サービスディスカバリによって成⽴
    apiVersion: v1
    kind: Service
    metadata:
    name: sample-svc
    spec:
    type: LoadBalancer
    ports:
    - name: "http-port"
    protocol: "TCP"
    port: 8080
    targetPort: 80
    selector:
    app: a
    LB
    (name: sample-svc)
    http://sample-svc.default.svc.cluster.local
    [Kubernetes] IP アドレスの管理

    View full-size slide

  41. クラスタ外部からの通信も external-dns を利⽤して
    グローバル IP を外部 DNS に⾃動登録させることが可能
    1. ロードバランサにグローバル IP が⾃動的に払い出される
    2. 外部の DNS に⾃動的にグローバル IP を登録
    さらに cert-manager を利⽤することで
    ACME を利⽤して証明書の⾃動発⾏/更新も可能
    LB
    xxx.xxx.xxx.xxx
    外部 DNS
    amsy.dev =>
    xxx.xxx.xxx.xxx
    [Kubernetes] IP アドレスの管理

    View full-size slide

  42. Kubernetes ͷίΞίϯηϓτ
    Reconciliation Loop

    View full-size slide

  43. あるべき理想の状態(Desired State)≒ Declarative へと収束する
    何か問題が発⽣した場合でも、Controller により セルフヒーリングされる
    ※ 厳密には Controller も API を⽤いて変更します。
    reconcile()
    {

    }
    登録
    (via API Request)
    Watch
    クラスタの状態
    コンテナの作成・削除
    Controller
    登録された時に、ただ起動させるだけではない
    Kubernetes と Reconciliation Loop

    View full-size slide

  44. Controller 内では Reconciliation loop(調整ループ)と呼ばれる
    あるべき状態へと収束させるループ処理 が実⾏されている
    Kubernetes の内部には様々な Controller と呼ばれるプログラムが動作している
    Observe
    Diff
    Act Observe: 現状を確認
    Diff: 理想と現実の差分を計算
    Act: 差分に対する処理を実施
    reconcile()
    {

    }
    Controller
    Kubernetes と Reconciliation Loop

    View full-size slide

  45. ReplicaSet Controller の責務は
    「指定されたレプリカ数で Pod を維持し続けること」
    Observe
    Diff
    Act
    Observe: 現状を確認
    Diff: 理想と現実の差分を計算
    Act: 差分に対する処理を実施
    クラスタの状態
    理想の状態
    reconcile()
    {

    }
    Controller
    例: ReplicaSet Controller の例

    View full-size slide

  46. 例えば、コンテナ(Pod)を 3 つ起動させる ReplicaSet リソースの場合
    Observe
    Diff
    Act
    Observe: 現状を確認
    Diff: 理想と現実の差分を計算
    Act: 差分に対する処理を実施
    クラスタの状態
    理想の状態
    reconcile()
    {

    }
    Controller
    例: ReplicaSet Controller の例

    View full-size slide

  47. たとえば 2 つしかコンテナ(Pod)が起動していない場合…
    Observe: 理想=3、現状=2
    Observe
    Diff
    Act
    Observe: 現状を確認
    Diff: 理想と現実の差分を計算
    Act: 差分に対する処理を実施
    クラスタの状態
    理想の状態
    reconcile()
    {

    }
    Controller
    例: ReplicaSet Controller の例

    View full-size slide

  48. たとえば 2 つしかコンテナ(Pod)が起動していない場合…
    Diff: 1 つコンテナ(Pod)が⾜りない
    Observe
    Diff
    Act
    Observe: 現状を確認
    Diff: 理想と現実の差分を計算
    Act: 差分に対する処理を実施
    クラスタの状態
    理想の状態
    reconcile()
    {

    }
    Controller
    例: ReplicaSet Controller の例

    View full-size slide

  49. たとえば 2 つしかコンテナ(Pod)が起動していない場合…
    Act: 1つ nginx:1.12 のコンテナ(Pod)を作成する
    Observe
    Diff
    Act
    Observe: 現状を確認
    Diff: 理想と現実の差分を計算
    Act: 差分に対する処理を実施
    クラスタの状態
    理想の状態
    reconcile()
    {

    }
    Controller
    例: ReplicaSet Controller の例

    View full-size slide

  50. 実際にはすべてが Kubernetes API 上のリソースとして表現されている
    Controllerの中⾝ = API の操作 + ロジック
    例: ReplicaSet Controller の例
    reconcile()
    {

    }
    Controller
    ReplicaSet の監視
    Pod の制御
    via API
    運⽤のコード化

    View full-size slide

  51. Kubernetes の構成要素
    リソースのスキーマ + Controller + およびその仕組み
    Kubernetes では⾮常に沢⼭の Controller が動いている
    • ReplicaSet Controller
    • Deployment Controller
    • Ingress Controller
    • Node Controller
    • Scheduler
    • etc.
    これらの Controller が⾮同期に動作することで
    ⼀つの分散システムとして成り⽴っている
    reconcile()
    {

    }
    Controller
    reconcile()
    {

    }
    Controller
    reconcile()
    {

    }
    Controller
    reconcile()
    {

    }
    Controller
    reconcile()
    {

    }
    Controller
    実際の状態
    理想の状態
    watch

    View full-size slide

  52. 実際にはすべてが Kubernetes API 上のリソースとして表現されている
    Controllerの中⾝ = API の操作 + ロジック
    └─ kubebuilder, Operator Framework などによりフレームワーク化
    MySQL Controller の例 (mysql-operator)
    reconcile()
    {

    }
    Controller
    独⾃リソースの監視
    Pod などの制御
    via API
    運⽤のコード化

    View full-size slide

  53. ͦͯ͢͠΂͕ͯ Kubernetes YAML ʹͳΔ
    ≒ Θ͕ͨ͠ Container Orchestrator ͱͯ͠
    Kuebrnetes ʹະདྷΛײ͍ͯ͡Δ෦෼

    View full-size slide

  54. Controller による運用の自動化パターン(1/3)
    1.⼀般的な運⽤⾃動化ロジック
    • 社内に伝わる秘伝の闇の運⽤スクリプトを駆逐
    • Kubernetes-way な統⼀化された⽅法
    • Reconciliation モデルにより「運⽤」のロジック化に適している
    • 汎化した形で実装し、オープンソースのエコシステムとして共有
    例)
    リポジトリのマニフェストを Kubernetes に apply する︓ArgoCD
    払い出されたロードバランサの IP アドレスを DNS に登録する︓ExternalDNS
    Issuer から証明書を発⾏して Secret として登録する︓Cert Manager
    コンテナのリソースの使⽤率から⾃動的にリソース割当を変える︓VerticalPodAutoscaler

    View full-size slide

  55. Controller による運用の自動化パターン(2/3)
    2.ステートフルなミドルウェアを運⽤する Controller がつくられる
    Databaseなどの運⽤を任せられる時代に。
    Message Queue/KVS に関しては近いうちに現実的に
    (個⼈的にステートを持つ Computing リソースの延⻑に感じている)
    ステートフルなミドルウェアが進まない理由
    • Podのライフサイクルに適応できるものが少ない
    • 現状はクラスタ間のボリューム移⾏が得意ではない

    View full-size slide

  56. Controller による運用の自動化パターン(3/3)
    Computing
    Computing
    定期的な運⽤が必要
    3.外部システムを制御・運⽤するための仕組み
    • Reconcile を踏襲した管理
    • e.g. Config Connector︓ GCP リソースの制御
    既存の問題点
    1.クラウドリソースが適切な状態か判別できない
    Terraformなどは構築ツール的
    2.管理系が複数に分かれている
    認証情報等はどうするか

    View full-size slide

  57. Controller による運用の自動化パターン(3/3)
    KVS
    DB
    Computing
    Computing
    KVS (meta)
    DB (meta)
    3.外部システムを制御・運⽤するための仕組み
    • Reconcile を踏襲した管理
    • e.g. Config Connector︓ GCP リソースの制御
    既存の問題点
    1.クラウドリソースが適切な状態か判別できない
    Terraformなどは構築ツール的
    => Controller 内ロジックにより担保
    2.管理系が複数に分かれている
    認証情報等はどうするか
    => Secret リソースとして⾃動展開し
    アプリから利⽤可能に(CCに機能的にあるか不明)
    定期的な運⽤

    View full-size slide

  58. 今回のスコープだと残るコード
    Dockerfile
    • アプリケーションのパッケージングに関するコードのみ
    • Cloud Native Build Pack(各⾔語のツール含む)により
    Dockerfile が不要になる世界も
    Terraform
    • IP アドレスの確保 や クラスタの初期構築
    • ExternalDNS や Cert Manager の活⽤により IP アドレスフリーに
    • クラスタ運⽤は⾃動化へ

    View full-size slide

  59. クラスタ運用の自動化
    Node Auto Healing(like Self-healing of ReplicaSet)
    Kubernetes Node に問題が⽣じた場合にノードの復旧を⾏う
    Cluster Auto Upgrade(like Rolling Update of Deployment)
    Kubernetes の Master 及び Node のコンポーネント郡の Rolling Upgrade
    Cluster Autoscaling(like HorizontalPodAutoscaler)
    Kubernetes Node を追加/削除してクラスタのスケーリングを⾏う
    Node Auto Provisioning(like VerticalPodAutoscaler)
    適切なサイズ・種別のノードを⾃動判別してクラスタに追加

    View full-size slide

  60. まとめ
    Cloud Native とは、アプリケーションの実⾏を第⼀に考えたときに
    どういうインフラを作るかということを主軸にした考え⽅とも⾔える
    Controller による⾃動化のパターン
    ⼀般的な運⽤⾃動化
    ステートフルなミドルウェアの運⽤
    外部システムを制御・運⽤する仕組み
    VM時代との⽐較
    即座に安定したビルド〜デプロイを実現するイメージ化
    運⽤のベストプラクティス
    インフラの抽象化
    Kubernetes は宣⾔的API + Controller による Reconciliation Loop により
    運⽤⾃動化を⾏うエコシステムを⽀えている

    View full-size slide

  61. 5 年後の一般的なインフラ環境の未来
    オンプレ環境
    「データベース以外はKubernetes上で稼働している状態」
    パブリッククラウド環境
    「Kubernetes 上ですべてが管理されている状態」

    View full-size slide

  62. Kubernetes-native testbed for the future (still alpha release)
    https://employment.en-japan.com/engineerhub/entry/2020/04/16/103000

    View full-size slide

  63. ͦͯ͢͠΂͕ͯ Kubernetes YAML ʹͳΔ
    ͦͯ͢͠΂͕ͯ Kubernetes-native ʹͳΔ

    View full-size slide

  64. ຊ౰ͷ࠷ޙʹ

    View full-size slide

  65. ຊ౰ͷ࠷ޙʹ
    ಥવͷએ఻

    View full-size slide

  66. CloudNative Days Tokyo 2020 (9/8 - 9/9)
    今年はオンライン開催になりました!
    CFP・スポンサー募集中です!
    http://bit.ly/cndt2020cfp
    About CloudNative Days
    CloudNative Days はコミュニティ、企業、技術者が一堂に
    会し、クラウドネイティブムーブメントを牽引することを
    目的としたテックカンファレンスです。
    最新の活用事例や先進的なアーキテクチャを学べるのはも
    ちろん、ナレッジの共有やディスカッションの場を通じて
    登壇者と参加者、参加者同士の繋がりを深め、初心者から
    熟練者までが共に成長できる機会を提供します。
    皆様がクラウドネイティブ技術を適切に選択し、活用し、
    次のステップに進む手助けになることを願っています。
    クラウドネイティブで、未来を共に創造しましょう。

    View full-size slide

  67. CloudNative Days Tokyo 2020 (9/8 - 9/9)
    今年はオンライン開催になりました!
    CFP・スポンサー募集中です!
    http://bit.ly/cndt2020cfp
    About CloudNative Days
    CloudNative Days はコミュニティ、企業、技術者が一堂に
    会し、クラウドネイティブムーブメントを牽引することを
    目的としたテックカンファレンスです。
    最新の活用事例や先進的なアーキテクチャを学べるのはも
    ちろん、ナレッジの共有やディスカッションの場を通じて
    登壇者と参加者、参加者同士の繋がりを深め、初心者から
    熟練者までが共に成長できる機会を提供します。
    皆様がクラウドネイティブ技術を適切に選択し、活用し、
    次のステップに進む手助けになることを願っています。
    クラウドネイティブで、未来を共に創造しましょう。
    ొஃऀٻΉ

    View full-size slide

  68. Thank you for your attention
    Twitter: @amsy810

    View full-size slide