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

Kubernetesって何ができるの?どうなってるの?

 Kubernetesって何ができるの?どうなってるの?

Kubernetes入門向けの資料です。
@さくらの夕べ Docker/Kubernetesナイト

お受けした質問の一部はこちらのツイートに紐づく形で回答しています → https://twitter.com/amaya382/status/1140559260234833920

補足) わかりやすさのため、説明を簡略化している・少々乱暴な表現をしている部分があります。また、一部機能の紹介では、k8s本体のみでなく周辺ツールを前提としたものも含まれます。

Ryuichi Ito

June 17, 2019
Tweet

More Decks by Ryuichi Ito

Other Decks in Technology

Transcript

  1. ⾃⼰紹介 伊藤⻯⼀ しごと • 所属: 技術本部 アプリケーショングループ • 新規プロジェクト×2でKubernetesを導⼊中 •

    1つはAPIサーバのデプロイ先、バッチ処理実⾏環境として • 1つはスケーラブルなデータ処理基盤として こじん • Twitter: @amaya382 • Kubernetesに関する同⼈誌を書いたり • 技術書典7もKubernetes関係で模索中 2
  2. 対象者とゴール 前提 • コンテナ型仮想化をなんとなく知っている • Dockerを触ったことがある 対象者 • Kubernetesという得体の知れないものの概要を知りたい •

    Docker化したアプリのいい感じのデプロイ先を探している ゴール • 概要を把握する • メリット・デメリットを把握する • 実運⽤する場合に何が必要になるかを知る 3
  3. Kubernetesって何? そもそも読み⽅がよく分からん • Kubernetes: クーバーネィティス (諸説あり) • k8s: ケーエイツ (ケーハチエス)

    • kube*: キューブ* コンテナオーケストレーションシステム • コンテナ間のネットワークの管理 • 計算機リソースの分配 • ⾃動的なデプロイ・スケール・障害時復旧 • etc. ※Docker以外にも対応しているが、殆どの場合Dockerと利⽤される 5 コンテナベースのアプリを 本番運⽤するに必要な機能群
  4. Kubernetesって何? そもそも読み⽅がよく分からん • Kubernetes: クーバーネィティス (諸説あり) • k8s: ケーエイツ (ケーハチエス)

    • kube*: キューブ* コンテナオーケストレーションシステム • コンテナ間のネットワークの管理 • 計算機リソースの分配 • ⾃動的なデプロイ・スケール・障害時復旧 • etc. ※Docker以外にも対応しているが、殆どの場合Dockerと利⽤される 6 コンテナベースのアプリを 本番運⽤するに必要な機能群
  5. Kubernetesって何? そもそも読み⽅がよく分からん • Kubernetes: クーバーネィティス (諸説あり) • k8s: ケーエイツ (ケーハチエス)

    • kube*: キューブ* コンテナオーケストレーションシステム • コンテナ間のネットワークの管理 • 計算機リソースの分配 • ⾃動的なデプロイ・スケール・障害時復旧 • etc. ※Docker以外にも対応しているが、殆どの場合Dockerと利⽤される 7 コンテナベースのアプリを 本番運⽤するに必要な機能群 どこで 動かそう?
  6. Kubernetesって何? そもそも読み⽅がよく分からん • Kubernetes: クーバーネィティス (諸説あり) • k8s: ケーエイツ (ケーハチエス)

    • kube*: キューブ* コンテナオーケストレーションシステム • コンテナ間のネットワークの管理 • 計算機リソースの分配 • ⾃動的なデプロイ・スケール・障害時復旧 • etc. ※Docker以外にも対応しているが、殆どの場合Dockerと利⽤される 8 コンテナベースのアプリを 本番運⽤するに必要な機能群 いっぱいだ 増やそう
  7. k8sで何ができるようになるの? スケールが容易 • 各サービスごとのリソースプールのスケール • 全体のリソースプールのスケール 対障害性 • k8sを構成するコンポーネントそれぞれで冗⻑化可能 •

    部分的に障害が起きても、⾃動的に修復 • ほとんどがステートレス • 最悪の場合でも環境ごと作り直しやすい 10 バースト対応も 設定1つ⼊れるだけ
  8. k8sで何ができるようになるの? ⾼度な制御が可能 • アクセス制御 • アカウント権限管理 • Role-Based Access Control(RBAC)

    どこでも動くしなんでも動く • ベンダー⾮依存 • GPUready、機械学習基盤にも 11 クラウド+オンプレのハイブリッド なんてことも可能 「あーるばっく」と発⾳するらしい データベースAはアプリXから しかアクセスできません!
  9. k8sで何ができるようになるの? ⼿厚いデプロイのサポート • 無停⽌アップデート • ローリングアップデート • Blue-Green • 特定の状態にロールバック

    • 宣⾔的・冪等性 • テキストベースのマニフェスト • 「アプリコンテナを4個、nginxコンテナを2個、DBコンテナを2個。あ、でも負荷が⾼い時は nginxコンテナを5個まで⾃動で増やして!DBコンテナにアクセスできるのはアプリコンテ ナだけでよろ!」 • 環境の再現が容易 13 実運⽤で超重要!
  10. ユースケース マイクロサービス • 相性◎な機能が豊富 • オートスケール • サーキットブレイク • ロールアウト

    • アクセス制御 16 特定サービスの負荷が上がったら、 そのサービスだけを ⾃動的にスケールアウト! 特定サービスに障害が発⽣したら、 そのサービスだけを切り離し!
  11. ユースケース マイクロサービス • 相性◎な機能が豊富 • オートスケール • サーキットブレイク • ロールアウト

    • アクセス制御 17 無停⽌でサービスをアップデート! 特定のサービス間のみに制限して セキュリティリスクを抑制
  12. k8sの持つ2つの側⾯ • DevOpsを強く意識 • 複数レイヤのエンジニアが歩み寄った先 「k8sを使うぞ!やっていくぞ!」となったとき、 協調しつつも⼤きく2つに役割が分かれる • Admin •

    インフラエンジニア+運⽤エンジニア クラスタの作成・権限管理・運⽤・監視 • ApplicationDeveloper • ミドルウェアエンジニア+ソフトウェアエンジニア クラスタ上で動かすサービスの構築・開発・運⽤ 20
  13. Application Developerからみたk8s 21 有効 v1 v2 無効 Node Deployment ReplicaSet

    Pod Container Internet ユーザ Service ※簡略化済 物理マシンやVM1台と対応
  14. Application Developerからみたk8s 22 有効 v1 v2 無効 Node Deployment ReplicaSet

    Pod Container Internet ユーザ Service ※簡略化済 主にReplicaSetを世代別管理 ロールバック等を実現
  15. Application Developerからみたk8s 23 有効 v1 v2 無効 Node Deployment ReplicaSet

    Pod Container Internet ユーザ Service ※簡略化済 Podを管理
  16. Application Developerからみたk8s 24 有効 v1 v2 無効 Node Deployment ReplicaSet

    Pod Container Internet ユーザ Service ※簡略化済 Containerの集まり 必ずNode上に収まる
  17. Application Developerからみたk8s 25 有効 v1 v2 無効 Node Deployment ReplicaSet

    Pod Container Internet ユーザ Service ※簡略化済 Docker等のコンテナそのもの (つまりNodeのプロセス)
  18. Application Developerからみたk8s 26 有効 v1 v2 無効 Node Deployment ReplicaSet

    Pod Container Internet ユーザ Service ※簡略化済 アプリへの疎通を管理
  19. Application Developerからみたk8s 27 有効 v1 v2 無効 Node Deployment ReplicaSet

    Pod Container Internet ユーザ Service 内部IP: XXX.XXX.XXX.1 内部IP: XXX.XXX.XXX.2 Local IP: YYY.YYY.YYY.1 Local IP: YYY.YYY.YYY.2 Global IP: ZZZ.ZZZ.ZZZ.1 https://ZZZ.ZZZ.ZZZ.1 ※簡略化済
  20. k8s Adminからみたk8s 28 Master etcd Admin kube-apiserver kube-scheduler controller-manager kube-proxy

    kubelet Node Docker Pod Container ユーザ Load Balancer kube-proxy kubelet ※簡略化済 設定を更新 ⾃Nodeのあるべき状態をPull
  21. k8s Adminからみたk8s 29 Master etcd Admin kube-apiserver kube-scheduler controller-manager kube-proxy

    kubelet Node Docker Pod Container ユーザ Load Balancer kube-proxy kubelet ※簡略化済 全てのアクセスをプロキシ ※k8s管理下だが k8s外のリソース
  22. 環境 ⾃前 • kubeadm (≒⼿動) • Rancher • kubespray 開発向けローカル環境

    • Linux: microk8s • Win/Mac: minikube Kubernetes as a Service(KaaS) • Google Kubernetes Engine(GKE) • AmazonElasticContainerServiceforKubernetes(EKS) • AzureKubernetesService(AKS) 31 本番環境にも利⽤でき、 Adminが不要 やはり⼿元で動かせるのは便利
  23. • スタートアップスクリプトのRancherを使う • Rancher経由でk8sクラスタ作成 • https://qiita.com/zembutsu/items/41837d953a518c0b7f9e • ⼿作り • ルーター+スイッチ配下にk8sクラスタを作る

    (ちょっとだけオプションが追加で必要) • sakura-cloud-controller-managerをインストール • LoadBalancerが使えるようになる • Service作成の際にロードバランサ関係のメタデータを付与 32
  24. ツール kubectl: CLIツール • kubectl create deployment --image=nginx mynginx •

    「mynginx」という名前のnginxのDeploymentを作成 • Deploymentに紐づく形で、ReplicaSet・Pod・Containerも作成される • kubectl expose deployment mynginx \ --type=LoadBalancer --port=80 • 「mynginx」という名前のDeploymentの80番ポートを LoadBalancer経由でアクセス可能にするServiceを作成 • 外部のLoadBalancerが⾃動的に払い出される • kubectl get deployment mynginx -o=yaml • 「mynginx」という名前のDeploymentの情報をYAML形式で取得 • kubectl apply -f nginx-deploy.yaml • 「nginx-deploy.yaml」というファイルの設定を適⽤ • このYAML形式ファイルを「Manifest」と呼ぶ 33
  25. Manifestとは k8s設定のコード化を実現しているもの • YAMLやJSONで表現される • APIに直接対応 • 独⾃の定義で拡張可能 34 apiVersion:

    apps/v1 kind: Deployment metadata: labels: app: debugkit name: debugkit spec: replicas: 1 selector: matchLabels: app: debugkit template: metadata: labels: app: debugkit spec: containers: - image: amaya382/k8s-debugkit name: k8s-debugkit 例えば、 k8s上でWorkflowを実現
  26. まとめ ベンダー⾮依存・コンテナベース・⼀貫したコードで管理可能な IaaS+PaaS • その分学習コストは⾼い • k8s⾃体の構築・運⽤もやや難しい • とはいえカバー範囲を考えれば⼗分すぎるリターン 導⼊が検討できる環境

    • アプリがコンテナ化されている • インフラ管理で疲弊している • アプリの更新頻度が⾼い • アプリの構成要素が多い • スパイクアクセスが発⽣する 35 KaaSであれば、 構築・運⽤をスキップ可能。 IaaS+Terraform+Ansible等 で頑張ってきたことが⼀⼿に! 例えば、「WordPress を1つ2つ動かしたい」 程度には全く不適