Kubernetesって 何ができるの？どうなってるの？ @さくらの⼣べ Docker/Kubernetesナイト 技術本部 2019/6/17 伊藤⻯⼀ (@amaya382) 

⾃⼰紹介 伊藤⻯⼀ しごと • 所属: 技術本部 アプリケーショングループ • 新規プロジェクト×2でKubernetesを導⼊中 • 1つはAPIサーバのデプロイ先、バッチ処理実⾏環境として • 1つはスケーラブルなデータ処理基盤として こじん • Twitter: @amaya382 • Kubernetesに関する同⼈誌を書いたり • 技術書典7もKubernetes関係で模索中 2 

対象者とゴール 前提 • コンテナ型仮想化をなんとなく知っている • Dockerを触ったことがある 対象者 • Kubernetesという得体の知れないものの概要を知りたい • Docker化したアプリのいい感じのデプロイ先を探している ゴール • 概要を把握する • メリット・デメリットを把握する • 実運⽤する場合に何が必要になるかを知る 3 

始める前に… Kubernetes使ったことありますか？ • ﾅﾆｿﾚｵｲｼｲﾉ？名前しか知らない… • Nginxとかデプロイしてみたことあるよ • 本格利⽤すべく、いろいろな機能を試しているよ • がっつり本格利⽤しているよ 4 

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

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

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

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

なぜk8s？ 「Dockerだけじゃだめなの？」 • DockerはあくまでContainerを動かすところまで • 複数ノードになるとカバーしきれない部分が出てくる 「似たようなプロダクトに、Mesos、DockerSwarm、Consulと かあるらしいけど？」 • 正直⼀⻑⼀短。だが、将来性がありデファクトになりつつある 9 ECSを提供していた AmazonでさえEKSに⼒ を⼊れているほど 他のプロダクトと⽐較して 複雑だが⾼機能・⾼性能 

k8sで何ができるようになるの？ スケールが容易 • 各サービスごとのリソースプールのスケール • 全体のリソースプールのスケール 対障害性 • k8sを構成するコンポーネントそれぞれで冗⻑化可能 • 部分的に障害が起きても、⾃動的に修復 • ほとんどがステートレス • 最悪の場合でも環境ごと作り直しやすい 10 バースト対応も 設定1つ⼊れるだけ 

k8sで何ができるようになるの？ ⾼度な制御が可能 • アクセス制御 • アカウント権限管理 • Role-Based Access Control
(RBAC) どこでも動くしなんでも動く • ベンダー⾮依存 • GPU
ready、機械学習基盤にも 11 クラウド+オンプレのハイブリッド なんてことも可能 「あーるばっく」と発⾳するらしい データベースAはアプリXから しかアクセスできません！ 

k8sで何ができるようになるの？ ミドルウェアレベルまで全て織り込み済み • ロードバランサはデフォルトで⾃動作成 • L7ReverseProxyもアプリの延⻑で設定可能 • 個別にNginx/Apache等を建てて管理する必要なし 12 

k8sで何ができるようになるの？ ⼿厚いデプロイのサポート • 無停⽌アップデート • ローリングアップデート • Blue-Green • 特定の状態にロールバック • 宣⾔的・冪等性 • テキストベースのマニフェスト • 「アプリコンテナを4個、nginxコンテナを2個、DBコンテナを2個。あ、でも負荷が⾼い時は nginxコンテナを5個まで⾃動で増やして！DBコンテナにアクセスできるのはアプリコンテ ナだけでよろ！」 • 環境の再現が容易 13 実運⽤で超重要！ 

k8sで何ができるようになるの？ ⼀⾔で⾔うと、 『ベンダ⾮依存・コンテナベース・全てコードで管理可能な フルスタックIaaS+PaaS』 • とにかく運⽤で楽ができる！アプリの⾮機能要件にも強い！最⾼！！！ • が、痛みも伴う… • 学習コストは特⼤ • 構築コストも特⼤ 14 構成を誤ると運⽤コストも下げられない →詳細はこの後のGitOpsにて！ 

ユースケース 15 

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

ユースケース マイクロサービス • 相性◎な機能が豊富 • オートスケール • サーキットブレイク • ロールアウト • アクセス制御 17 無停⽌でサービスをアップデート！ 特定のサービス間のみに制限して セキュリティリスクを抑制 

ユースケース JupyterHub • JupyterNotebook環境をユーザごとに作るためのシステム • k8sを計算リソースプールとして利⽤ • リクエストが来ると、バックエンドに配備されたk8sに JupyterNotebookのインスタンスが作成される • 様々な機械学習向けツールを内包したKubeflowも 流⾏り始めている 18 

仕組み 19 

k8sの持つ2つの側⾯ • DevOpsを強く意識 • 複数レイヤのエンジニアが歩み寄った先 「k8sを使うぞ！やっていくぞ！」となったとき、 協調しつつも⼤きく2つに役割が分かれる • Admin • インフラエンジニア+運⽤エンジニア クラスタの作成・権限管理・運⽤・監視 • Application
Developer • ミドルウェアエンジニア+ソフトウェアエンジニア クラスタ上で動かすサービスの構築・開発・運⽤ 20 

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

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

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

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

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

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

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 ※簡略化済 

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 

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外のリソース 

動かすには 30 

環境 ⾃前 • kubeadm (≒⼿動) • Rancher • kubespray 開発向けローカル環境 • Linux: microk8s • Win/Mac: minikube Kubernetes as a Service
(KaaS) • Google Kubernetes Engine
(GKE) • Amazon
Elastic
Container
Service
for
Kubernetes
(EKS) • Azure
Kubernetes
Service
(AKS) 31 本番環境にも利⽤でき、 Adminが不要 やはり⼿元で動かせるのは便利 

• スタートアップスクリプトのRancherを使う • Rancher経由でk8sクラスタ作成 • https://qiita.com/zembutsu/items/41837d953a518c0b7f9e • ⼿作り • ルーター+スイッチ配下にk8sクラスタを作る (ちょっとだけオプションが追加で必要) • sakura-cloud-controller-managerをインストール • LoadBalancerが使えるようになる • Service作成の際にロードバランサ関係のメタデータを付与 32 

ツール 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 

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を実現 

まとめ ベンダー⾮依存・コンテナベース・⼀貫したコードで管理可能な IaaS+PaaS • その分学習コストは⾼い • k8s⾃体の構築・運⽤もやや難しい • とはいえカバー範囲を考えれば⼗分すぎるリターン 導⼊が検討できる環境 • アプリがコンテナ化されている • インフラ管理で疲弊している • アプリの更新頻度が⾼い • アプリの構成要素が多い • スパイクアクセスが発⽣する 35 KaaSであれば、 構築・運⽤をスキップ可能。 IaaS+Terraform+Ansible等 で頑張ってきたことが⼀⼿に！ 例えば、「WordPress を1つ2つ動かしたい」 程度には全く不適