半日でわかるコンテナー技術 (応用編)

半日でわかるコンテナー技術 (応用編)
真壁徹
日本マイクロソフト株式会社
クラウドソリューションアーキテクト
2018/11/21
WebブラウザーとAzureで手を動かして学ぶ

自己紹介
{
“名前” : “真壁徹(まかべとおる)”,
“所属” : “日本マイクロソフト株式会社”,
“役割” : “クラウドソリューションアーキテクト”,
“経歴” : “大和総研 → HP Enterprise”,
“特技” : “クラウド & オープンソース”,
“資格” : “CNCF Certified Kubernetes Admin.”,
“Twitter” : “@tmak_tw”
}

アジェンダ
13:00～13:30 コンセプト説明と作業環境の確認
(Azure Cloud Shell、リソースグループ作成権限)
13:30～15:00 Kubernetes 基礎知識
15:00～15:15 休憩
15:15～16:15 Kubernetes インフラ応用(スケール/修復)
16:15～17:15 Kubernetes アプリ開発応用 (CI/CD)
17:15～ Q&A

コンセプト
この半日の

コンテナー技術を学びたい、でも
環境が先か、体験が先か
端末にソフト導入の自由度とそれなりのスペックを要求される
(Docker for Windows/Mac、仮想化、メモリ量、etc)
企業で貸与されている端末で動かないケースも多い
必要であれば端末購入を申請したいが、説得材料に欠ける
コンテナー技術が自らの課題に効果的かどうか、体験、実感したい
気軽にコンテナー技術を試せる機会があれば…

おまかせください
WebブラウザーとAzureのみで体験しましょう
Azureの利用権と対応するWebブラウザーがあればOKです
Azure Cloud Shellとコンテナー技術対応サービスを活用します
コンテナー技術のコンセプトや動作、開発の流れを体験できます
利点や効果を実感できたら、端末など環境整備をご検討ください
(現時点ではまだ、端末上での開発が効率的です)

環境確認
手を動かす前に

ご確認ください
サポートするWebブラウザー
Azure Portal でサポートされるブラウザーとデバイス
Azureポータルにログインし、Cloud Shell を起動してください
ポータル
上部の、ここ

以降の演習はすべてAzure Cloud
Shell上で行います

$ cd clouddrive
$ git clone https://github.com/ToruMakabe/container-handson.git
$ cd container-handson/advanced
演習用リポジトリを取得し、移動
$HOME/clouddrive 以下はAzure
Filesのファイルシェアとして参照で
きるため、作業ディレクトリとして
おすすめ (必須ではありません)

Azure Cloud Shellのエディタ環境
お好きなものを
emacs、nano、vim (アルファベット順)が入っています
簡易版Visual Studio Codeも使えます
“code” で
起動
メニュー
(ショートカットキーも
確認できます)

ユニークなプリフィックス(接頭辞)を考えましょう
本日の演習でリソース名が重複しないように
本日の演習ではサブスクリプションを共有する参加者がいます
プリフィックスを付けてユニークになるようにします
プリフィックスを英数字10文字程度で考えてください
例: ichisuzuki51

#!/bin/bash
PREFIX=“PREFIX"
SP="${PREFIX}-aks-handson"
RG="${PREFIX}-aks-handson-rg"
az ad sp create-for-rbac -n $SP
az group create -n $RG -l japaneast
環境準備スクリプト(prep.sh)を編集
ここを編集
(参考情報: Azureの命名規則)

$ ./prep.sh
(中略)
AppId DisplayName Name Password
Tenant
------------------------------------ -------------------- --------------------------- --------------------
---------------- ------------------------------------
aaa1a222-b2bb-33c3-4444-e5eee55ee55e tomakabe-aks-handson http://tomakabe-aks-handson 99f9ffff-8ff8-777f-
6666-55f555f5555 77a777aa-2b2-33cc-44dd-5e5ee555ee55
環境準備スクリプト(prep.sh)を実行し、結果を控える
AKSクラスター作成時にAppIdとPasswordを指定するので控えておきます
控えておきます控えておきます
(注)Azure CLIの出力形式をTableにしている例です。出力形式を変更していない場合はJSONで出力されます。
“az configure”コマンドで出力形式を変更できます。

もしもの時は
ハンズオンを進められない場合は
権限が足りなかったり、管理者が各種機能を無効化している場合は
Azureの無料アカウントを作成するもしくは、
Microsoft Learnで自習
(ラーニングパス: Azureでコンテナーを管理する)
2018/9末のMicrosoft Igniteで発表された自習サイト
保有サブスクリプションに影響を与えない「サンドボックス」で演習可能
コンテナーの他にも多様なテーマ、ラーニングパスあり

Kubernetes 基礎知識
第1部

Containers in Azure
Choice of developer tools and clients
Azure Container Registry Docker Hub
App Service
Azureの歴史ある
PaaSサービス
GitやVisual Studio
に限らずDockerコ
ンテナーでのデプ
ロイにも対応
Service Fabric
マイクロソフトの
開発する分散処理
基盤
.NETアプリケー
ションとの相性が
いい
Kubernetes Service Container Instance
コンテナーオーケスト
レーターの事実上標準
Ecosystem
パートナーとの
協業
コンテナー1つから
使えるマネージド
サービス
AKSの仮想ノードと
しても利用可能

Azureでコンテナーが使えるサービスの特徴
位置づけ汎用/特化課金リソース特記事項
Container
Instances
シンプルなコンテ
ナー実行基盤
汎用コンテナー利用
CPU・メモリ (秒)
KubernetesのNode
として利用可能
App Service (Web
App for
Containers)
WebアプリPaaS 特化(Webアプリ) App Service Plan
(秒)
部分的に
Kubernetes マニ
フェストをサポー
ト
Service Fabric 分散アプリ基盤汎用クラスター構成リ
ソース(主にVM)
(分)
.NETアプリとの親
和性が高い
Kubernetes Service コンテナーオーケ
ストレーター
汎用クラスター構成リ
ソース(主にVM)
(分)
事実上標準

誤解をおそれずに一言で
一言
Container Instances 使い捨てるコンテナーに
App Service (Web App for Containers) シンプルなWebアプリならKubernetesより断然手軽
Service Fabric .NETで、がっつり分散アプリを作るなら
Kubernetes Service 数多く、複数の種類のコンテナーを組み合わせて動かすなら

1. 開発者や管理者、各コンポーネン
トは、API Serverを通じて
Kubernetesに関する情報の取得や
操作を行う
2. Masterノードではクラスターの
各コンポーネントを「あるべき
姿」に維持する仕組みが動く
3. ユーザーアプリケーションは
Workerノードで動く (Workerと付
けずに Nodeと表現されることも
ある)
Kubernetes
control
API server
replication, namespace,
serviceaccounts, etc.
-controller-
manager -scheduler
etcd
Master node
Worker node
kubelet kube-proxy
Docker
Prod Prod
Containers Containers
Worker node
kubelet kube-proxy
Docker
Prod Prod
Containers Containers
Internet
4. アプリケーションのユーザーは
Workerノードへアクセスする
(Internetに限らず、プライベー
トネットワークに閉じることも
できる)
Kubernetes アーキテクチャー

Azure Kubernetes Service (AKS)
API server
Controller
ManagerScheduler
etcd
Store
Cloud
Controller
Self-managed master node(s)
• Kubernetesは構築や維持の負担が
大きいが、Azureはマネージドサー
ビスとして提供
• 可用性を高める仕組み
• 拡張性を高める仕組み
• 自己修復
• アップストリームに追従 (独自の
Kubernetesを作らない)
• MasterノードはAzureがサービスと
して管理しており、不可視
Customer VMs
App/
workload
definitionUser
Docker
Pods
Docker
Pods
Docker
Pods
Docker
Pods
Docker
Pods
Schedule pods over
private tunnel
Kubernetes
API endpoint
Azure managed control plane

Kubernetesクラスター作成に必要な作業
やること多すぎ
etcdの起動
Kubernetes設定ファイルの作成と配布
Kubernetesコンポーネント(バイナリー)
の配布
Kubernetesコンポーネントの起動
Kubernetesアドオンコンポーネントの作
成
などなど
Node間ネットワークの作成
Masterサーバーの作成
Masterサーバー向けロードバランサーの
作成
Nodeサーバーの作成
Pod間ネットワークの作成
証明書の作成と配布
etcd設定ファイルの作成と配布

AKS 物理/論理配置
Node
Node
Master (物理サーバー、仮想マシン) Node (物理サーバー、仮想マシン)
API Server
etcd
ロードバランサーロードバランサー
Controller
Manager
Scheduler
kubelet kube-proxy(*)
Container
Runtime
アドオンコン
ポーネント(**)
(*) Nodeのネットワークを制御 (iptables操作など)
(**) DNS、Metrics Serverなど (Podとして動く)
不可視
API エンドポイント
(例: hogehoge.hcp.japaneast.azmk8s.io)

Kubernetesを支える周辺機能
AKSの例

Cluster Bootstrapping
AKSの例
Deployment Engine

AKSクラスターの作成
演習

なぜサービスプリンシパルが必要か
人だけでなくKubernetesがAzureリソースを操作するため (Azure Load Balancerなど)
(*)Azure、GCP
などクラウド
APIの違いを吸
収する
この操作に必要な権限をサービス
プリンシパルとして指定する

!/bin/bash
PREFIX="PREFIX"
RG="${PREFIX}-aks-handson-rg"
AKS_CLUSTER_NAME="${PREFIX}-aks-handson"
AZ_SP_CLIENT_ID="YOUR-AZ-SP-CLIENT-ID"
AZ_SP_CLIENT_SECRET="YOUR-AZ-SP-CLIENT-SECRET"
(続く)
AKSクラスター作成スクリプト(deploy.sh)を編集 (1/2)
PREFIXは先ほどと同じ
YOUR-AZ-SP-CLIENT-IDを先ほど作成
したAppIdで置き換えます
YOUR-AZ-SP-CLIENT-SECRETを先ほ
ど作成したPasswordで置き換えます

(続き)
az aks create ¥
--resource-group $RG ¥
--name $AKS_CLUSTER_NAME ¥
--kubernetes-version 1.11.3 ¥
--node-count 2 ¥
--node-vm-size Standard_D2s_v3 ¥
--service-principal $AZ_SP_CLIENT_ID ¥
--client-secret $AZ_SP_CLIENT_SECRET
az aks get-credentials -g $RG -n $AKS_CLUSTER_NAME –admin --overwrite-existing
AKSクラスター作成スクリプト(deploy.sh)を編集 (2/2)
編集するところはありません
AKSクラスターの作成
AKSクラスターを操作するための
認証情報を取得

$ ./deploy.sh
(以下略)
AKSクラスター作成スクリプト(deploy.sh)を実行
少々時間がかかるので先に進みます

(前略)
Merged “PREFIX-aks-handson-admin" as current context in /home/YOUR-NAME/.kube/config
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-nodepool1-11483416-0 Ready agent 4m v1.11.3
aks-nodepool1-11483416-1 Ready agent 5m v1.11.3
AKSクラスターができあがっているころでしょうか
kubectlは、Kubernetesを操作するCLIです
kubectlの操作に必要な認証情報が
configファイルにマージされました

$ kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
heapster-5f8d5688-97c75 2/2 Running 0 1d
kube-dns-v20-54f74f4458-cj2gn 3/3 Running 0 2d
kube-dns-v20-54f74f4458-qc76p 3/3 Running 0 2d
kube-proxy-8ltdw 1/1 Running 0 1d
kube-proxy-fcqg8 1/1 Running 0 1d
kube-svc-redirect-fs55t 2/2 Running 0 2d
kube-svc-redirect-qxrtm 2/2 Running 0 2d
Kubernetes-dashboard-85c9c5944d-qqdhr 1/1 Running 1 2d
(以下略)
AKSクラスターで動く”Pod”

Podとは
Kubernetesのコンテナー実行単位
1つ以上のコンテナーをまとめてPodとする
Pod内のコンテナーはlocalhostで通信できる
Pod内のコンテナーはファイルのやり取りが可能
アプリコンテナー + 補助コンテナーという
使われ方が多い (サイドカー)
よくあるサイドカー: 認証、TLS化、ロギング、etc
Pod
Container Container

Namespace
Namespaceとは
Kubernetesクラスターを論理的に分割する単位
PodはNamespaceに属する
用途や利用者別にクラスターを
論理分割する仕組み
アクセス権限やリソース制限をNamespace単位で
付与できる
Namespaceを指定しないと、”default”が
選択される
Pod
Container Container
Pod
Container Container

$ kubectl get pod -n kube-system
heapster-5f8d5688-97c75 2/2 Running 0 1d
kube-dns-v20-54f74f4458-cj2gn 3/3 Running 0 2d
kube-dns-v20-54f74f4458-qc76p 3/3 Running 0 2d
kube-proxy-8ltdw 1/1 Running 0 1d
kube-proxy-fcqg8 1/1 Running 0 1d
kube-svc-redirect-fs55t 2/2 Running 0 2d
kube-svc-redirect-qxrtm 2/2 Running 0 2d
Kubernetes-dashboard-85c9c5944d-qqdhr 1/1 Running 1 2d
(以下略)
おさらい: AKSクラスターで動く”Pod”
Namespace “kube-system”にあるPodを取得していた
kube-systemではクラスターの機能や、管理す
るPodが動いている
(ユーザーアプリケーションと分離されている)

$ kubectl get pod -n kube-system -o wide
NAME READY STATUS RESTARTS AGE IP NODE
NOMINATED NODE
heapster-5f8d5688-97c75 2/2 Running 0 1d 10.244.1.7 aks-nodepool1-
11483416-0 <none>
kube-dns-v20-54f74f4458-cj2gn 3/3 Running 0 2d 10.244.0.7 aks-nodepool1-
11483416-1 <none>
kube-dns-v20-54f74f4458-qc76p 3/3 Running 0 2d 10.244.0.4 aks-nodepool1-
11483416-1 <none>
kube-proxy-8ltdw 1/1 Running 0 1d 10.240.0.4 aks-nodepool1-
11483416-0 <none>
(以下略)
詳しく表示するオプション –o wide

$ kubectl get namespace
NAME STATUS AGE
default Active 2d
kube-public Active 2d
kube-system Active 2d
$ kubectl get pod
No resources found.
$ kubectl get pod -n kube-public
No resources found.
他Namespaceの存在と、他NamespaceにあるPodの確認
-nオプションをつけないと
defaultが選択される

Kubernetesで
アプリケーションを動かしてみよう
演習

Kubernetesアプリケーションの主要構成要素
PodとReplicaSet、Deployment
Pod
Container Container
Pod
Container Container
Pod
Container Container
Pod
Container Container
Pod
Container Container
Pod
Container Container
Deployment
Revision:1 Revision:2
ReplicaSet ReplicaSet
DeploymentはReplicaSetのデプロイ単位
バージョン(リビジョン)管理ができる
ReplicaSetはPodを
負荷分散、冗長化するための複製
切り替え

Kubernetesアプリケーションの主要構成要素
Service
Service: Front
Serviceはサービス名とPodのIPアドレスを紐づけるしくみ -> サービス・ディスカバリ
これによりアプリケーションはPodのIPを直接指定する必要がない
(裏を返せば、動的に増減するPodのIPアドレスをいちいち指定するのは非現実的)
Pod
Label:
FrontPod
Label:
FrontPod
Label:
Front
Service: Back
Pod
Label:
FrontPod
Label:
FrontPod
Label:
Back
ユーザー
負荷分散負荷分散

サンプルアプリケーションの解説
Python Flaskフレームワーク + Redisによる投票アプリ
Service: azure-vote-front
Pod
Pod
Service: azure-vote-back
Pod
ユーザー
Flask
Container
Redis
Container
Deployment: azure-vote-front
レプリカ数: 2
Deployment: azure-vote-back
レプリカ数: 1
Azure Load Balancerと
パブリックIPに紐づけ

アプリケーションの定義
マニフェスト
コンテナー(Pod)1つであれば
kubectlでimageオプション指定すれば作れる
しかし、PodやDeploymentの多様なパラメーターを
kubectlでオプション指定するのはつらい
一般的には構成・バージョン管理も考慮し、
定義ファイル(マニフェスト)に記述する
YAMLかJSONで定義する (YAMLが読みやすい)
apiVersion: apps/v1
kind: Deployment
metadata:
name: azure-vote-back
spec:
replicas: 1
selector:
…..

apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 1
selector:
matchLabels:
app: azure-vote-back
template:
metadata:
labels:
spec:
containers:
- name: azure-vote-back
image: redis
ports:
- containerPort: 6379
name: redis
サンプルアプリマニフェスト (azure-vote-all-in-one-redis.yaml)
Docker Hubから
Redisの公式イメージを取得
投票データを蓄積するRedisのDeployment
Podにapp: azure-vote-back
というLabelを付与

apiVersion: v1
kind: Service
metadata:
spec:
ports:
- port: 6379
selector:
app: azure-vote-backというLabelのついているPodへ
“azure-vote-back”というサービス名でアクセスできるよ
うにする

apiVersion: apps/v1
kind: Deployment
metadata:
name: azure-vote-front
spec:
replicas: 2
selector:
matchLabels:
app: azure-vote-front
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
minReadySeconds: 5
(続く)
投票アプリのDeployment (1/2)
負荷分散、冗長化

(続き)
template:
metadata:
labels:
spec:
containers:
- name: azure-vote-front
image: torumakabe/vote:0.0.1
ports:
- containerPort: 80
resources:
requests:
cpu: 250m
limits:
cpu: 500m
env:
- name: REDIS
value: "azure-vote-back"
Docker Hubから
サンプルアプリイメージを
取得
環境変数として
接続するredisを指定(Service)
投票アプリのDeployment (2/2)
リソース要求と制限

apiVersion: v1
kind: Service
metadata:
spec:
type: LoadBalancer
ports:
- port: 80
selector:
type: LoadBalancer指定でサービスを作成する
Azureの場合は、Azure Load BalancerとパブリックIPが付
与される (プライベートIPも可能)

$ kubectl apply -f azure-vote-all-in-one-redis.yaml
deployment.apps/azure-vote-back created
service/azure-vote-back created
deployment.apps/azure-vote-front created
service/azure-vote-front created
$ kubectl get pod
azure-vote-back-f9cc849fb-hppjz 1/1 Running 0 1m
azure-vote-front-78cc84558d-9c55f 1/1 Running 0 1m
azure-vote-front-78cc84558d-pc5cj 1/1 Running 0 1m
$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
azure-vote-back ClusterIP 10.0.139.3 <none> 6379/TCP 2m
azure-vote-front LoadBalancer 10.0.98.143 40.115.179.115 80:31906/TCP 2m
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 2d
デプロイしてみましょう
マニフェストをファイル(-f)
で適用する
パブリックIPが振られるま
で少々待ちます
パブリックIPが振られたら、ブラウザでアクセスしてみましょう

$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
azure-vote-back 1 1 1 1 6m
azure-vote-front 2 2 2 2 6m
$ kubectl get replicasets
NAME DESIRED CURRENT READY AGE
azure-vote-back-f9cc849fb 1 1 1 6m
azure-vote-front-78cc84558d 2 2 2 6m
他にも出来上がったリソースを見てみましょう

(前略)
template:
metadata:
labels:
spec:
containers:
- name: azure-vote-front
image: torumakabe/vote:0.0.2
ports:
- containerPort: 80
resources:
requests:
cpu: 250m
limits:
cpu: 500m
env:
- name: REDIS
value: "azure-vote-back"
マニフェストを変更する (azure-vote-all-in-one-redis.yaml)
タグを0.0.2に変更
新バージョンのアプリ(コンテナー)をデプロイします

deployment.apps/azure-vote-back unchanged
service/azure-vote-back unchanged
deployment.apps/azure-vote-front configured
service/azure-vote-front unchanged
再デプロイしてみましょう
マニフェストをファイル(-f)で適用する
※1回目のデプロイと同じ
Deployment: azure-vote-
frontだけ変更された
先ほどと同じパブリックIPへブラウザでアクセスしてみましょう

おさらい
Kubernetesはコンテナーオーケストレーターの事実上標準
過剰でないかは気を付ける (コンテナー基盤は他にも選択肢がある)
Kubernetesクラスターの構築維持は手間がかかる
AKSはその負担を軽減するサービス
Kubernetesの主要構成要素 (Pod、ReplicaSet、Deployment、Service)
マニフェストを書き、デプロイする
マニフェストを変更し、デプロイする

Kubernetes インフラ応用
第2部

Kubernetesのリソース拡張手段
AKSでの選択肢
自動/手動水平/垂直(*) Pod/Node
HPA (Horizontal Pod
Autoscaler)
自動水平 Pod
VPA (Vertical Pod
Autoscaler)
自動垂直 Pod
CA (Cluster Autoscaler) 自動水平 Node
Replica数の定義変更手動水平 Pod
Azure CLI (az aks scale) 手動水平 Node
(*)水平 = Pod、Node数を増減する (サイズは同じ)
垂直 = Podのサイズを変更する

レプリカ数の定義変更
(マニフェストの変更)
演習

apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 3
selector:
matchLabels:
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
minReadySeconds: 5
(続く)
マニフェストを変更する (azure-vote-all-in-one-redis.yaml)
Deployment: azure-vote-front
レプリカ数を3に

deployment.apps/azure-vote-back unchanged
service/azure-vote-back unchanged
deployment.apps/azure-vote-front configured
service/azure-vote-front unchanged
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
azure-vote-back-f9cc849fb 1 1 1 8m
azure-vote-front-6755d8b845 3 3 3 8m
マニフェストの適用と確認
レプリカ数が3に
短縮名が使えます
replicasets = rs、pods = po など

spec:
containers:
- name: hoge
image: fuga
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
重要: Podのリソース定義 (RequestsとLimits)
Requests
“これくらい欲しい”
Limits
“これ以上は割り当てない”
ポイント
• Requestsは実際にリソースをどのくら
い使っているかと関係しない
• SchedulerがどのNodeへPodを割り当て
るかの判断に使う
• コンテナー個別に指定できる

Requestsを満たすようスケジューリングする
空きがない場合はPendingとなる
Node (割り当て可能メモリ 3Gi)
Pod A: Requests 1Gi Memory
Pod B: Requests 1Gi Memory
Pod C: Requests 1Gi Memory
Pod D: Requests 1Gi Memory
Scheduler
うーむ
Pod Dを割り当てる
空きがないのう
Pending
実際のメモリ利用
量は見ていない

HPA(Horizontal Pod Autoscaler)の仕組み
実際の利用量を見て、Podのレプリカを増減する
Node Node (***)
Pod(Replica3)
Pod(Replica1) Pod(Replica2)
Scheduler
API Server
HPA (**)
Metrics Server (*)
実際の利用量を
集めてくるよ
定義に合わせて
Podの数を
増減するよ
(*)以前はHeapsterが使われていました
Heapsterは廃止予定です
(**)カスタムメトリックも使えます
(Prometheusなど)
(***)Node上でcAdvisorがメトリックを集め、
kubelet経由でMetrics Serverに集約します

HPAの定義例
たとえば、全レプリカのCPU利用率をもとに判断する
Replica 1: 50%
(Requests: 100m,
Usage: 50m)
Replica 2: 50%
(Requests: 100m,
Usage: 50m)
Replica 3: 50%
(Requests: 100m,
Usage: 50m)
50%
50% + 50% + 50%
ターゲットの利用
率を定義
ターゲットの利用率を50%とし、すべてのレプリカの利用率が50%だったら(奇跡)
= 3
レプリカ数は
3のままでOK

HPAの定義例
たとえば、全レプリカのCPU利用率をもとに判断する
Replica 1: 90%
(Requests: 100m,
Usage: 90m)
Replica 2: 50%
(Requests: 100m,
Usage: 50m)
Replica 3: 70%
(Requests: 100m,
Usage: 70m)
50%
90% + 50% + 70%
ターゲットの利用
率を定義
レプリカ数を増やす必要がある場合
= 5
レプリカ数を
3から5に変更

HPA(Horizontal Pod Autoscaler)の仕組み
実際の利用量を見て、Podのレプリカを増減する
Node Node
Pod(Replica3)
Pod(Replica1) Pod(Replica2)
Scheduler
API Server
HPA
Metrics Server
実際の利用量を
集めてくるよ
定義に合わせて、
レプリカ数は5にす
るよ
Pod(Replica4)
Pod(Replica5)
おう
おう

HPAによるPod オートスケール
演習

(前略)
spec:
containers:
- image: k8s.gcr.io/hpa-example
imagePullPolicy: Always
name: php-apache
ports:
- containerPort: 80
protocol: TCP
resources:
requests:
cpu: 100m
limits:
cpu: 100m
(以下略)
サンプルアプリケーション(php-apache.yaml)
<?php
$x = 0.0001;
for ($i = 0; $i <= 1000000; $i++) {
$x += sqrt($x);
}
echo "OK!";
?>
k8s.gcr.io/hpa-example
アクセスすると無駄に負荷をアゲる
PHPアプリケーション
要求は
100ミリコア CPU

$ kubectl apply -f php-apache.yaml
deployment.apps/php-apache created
service/php-apache created
サンプルアプリケーションのデプロイ

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
maxReplicas: 10
minReplicas: 1
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: php-apache
targetCPUUtilizationPercentage: 30
サンプルHPA(php-apache-hpa.yaml)
PodのCPU利用率の
平均が30%を超え
たらPodを増やす
10レプリカまで

$ kubectl apply -f php-apache-hpa.yaml
horizontalpodautoscaler.autoscaling/php-apache created
$ kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache 0%/30% 1 10 1 42s
サンプルHPAのデプロイと確認
ターゲットの
利用率
実際の
利用率

$ kubectl run -it --rm load-generator --image=busybox /bin/sh
If you don't see a command prompt, try pressing enter.
/ # while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done
OK!OK!OK!OK!OK!OK!
負荷をかけてみましょう php-apacheにアクセスするコ
ンテナーを作り、接続
php-apacheに無限ループで
アクセスします

$ kubectl get hpa
php-apache Deployment/php-apache 52%/30% 1 10 4 9m
$ kubectl top pod
NAME CPU(cores) MEMORY(bytes)
azure-vote-back-f9cc849fb-rqbsr 0m 11Mi
azure-vote-front-6755d8b845-4rv2s 0m 45Mi
azure-vote-front-6755d8b845-7bj76 0m 38Mi
azure-vote-front-6755d8b845-bqbrk 0m 38Mi
azure-vote-front-6755d8b845-lq8gv 0m 40Mi
load-generator-779c5f458c-tt7ck 1m 0Mi
php-apache-8675c4f9d6-gl8kw 33m 12Mi
php-apache-8675c4f9d6-jkmfq 18m 11Mi
php-apache-8675c4f9d6-m5kwj 29m 12Mi
php-apache-8675c4f9d6-mdbnn 26m 12Mi
別のセッションから確認してみましょう
Cloud Shellのこのボタンで
新しいセッションが開きます
増えている
実際の利用量

/ # while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done
OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!O
K!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK
!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!
OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!O
K!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK! ^C
/ # exit
Session ended, resume using 'kubectl attach load-generator-779c5f458c-tt7ck -c load-generator -i -t' command
when the pod is running
deployment.apps "load-generator" deleted
$ kubectl get hpa
php-apache Deployment/php-apache 0%/30% 1 10 1 15m
元のセッションでアクセスを止めます
Ctl+c
exit
元に戻る

Nodeに空きリソースがなかったら？
Cluster Autoscalerの出番です
PendingのPodがある = 空きリソースがない
Cluster Autoscalerは、Pending状態のPodの有無でNode追加を判断
Cluster Autoscalerは、インフラのAPIを呼び出してNodeを追加
(AKSでは、Azure APIを呼んでいる)

CA(Cluster Autoscaler)
Pending状態のPodがあれば、Nodeを追加する
Cluster Autoscaler
Node Node
Pod(Running)
Pod(Running)
Pod(Running)
Pod(Running)
Pod(Running)
Pod(Running)
Scheduler
インフラAPI
Pod(Pending)
API Server
Node
PendingのPodを発見、
Nodeを増やすぞ
おう
Readyになったら
Schedulerから
Podを割り当てら
れる

HPAとCAの共演
それぞれ自律的に自分の仕事に集中し、結果的に連動する
Cluster Autoscaler
Node Node
Pod(Running)
Pod(Running)
Pod(Running)
Pod(Running)
Pod(Running)
Pod(Running)
Scheduler
インフラAPI
Pod(Pending)
API Server
Node
HPA
Metrics ServerHPAの定義を守るよ
う集中
PendingのPodの有無
に集中(※)
(※)Nodeを減らす判断は
Nodeのリソース割り当て状
況を見ている (詳細は割愛)
Readyになったら
Schedulerから
Podを割り当てら
れる

時間に余裕があれば演習
Cluster Autoscaler
公式ドキュメントチュートリアル
Cluster Autoscalerのバージョンに注意
(Kubernetesマイナーバージョンによって
推奨バージョンが異なる)
Kubernetes 1.11.x での推奨は
Cluster Autoscaler 1.3.x
README / Release
(前略)
spec:
serviceAccountName: cluster-autoscaler
containers:
- image: gcr.io/google-
containers/cluster-autoscaler:v1.2.2
imagePullPolicy: Always
name: cluster-autoscaler
(以下略)
ここ

可用性: Nodeの状態管理
Nodeは自律的に状態を報告する
Node 0
Pod A
Node 1
Pod B
API Server
10秒ごと(既定)に状態を報告
Node 0: Ready
Node 1: Ready
Controllers
(Node, ReplicaSets, etc)
Scheduler

可用性: Nodeがダウンしたら
各種ControllerとSchedulerがPodの作り直しを指示
Node 0
Pod A
Node 1
Pod B
API Server
Node 0: Ready
Node 1: NotReady
作成
Controllers
(Node, ReplicaSets, etc)
Scheduler
Node 1がおかしい
Pod Bに影響
Node 0で
作り直そう

疑似ノード故障からの自己修復
演習

$ kubectl get nodes
aks-nodepool1-11483416-0 Ready agent 2h v1.11.3
$ kubectl get po -o wide
NOMINATED NODE
azure-vote-back-f9cc849fb-rqbsr 1/1 Running 0 1h 10.244.1.3 aks-nodepool1-
11483416-0 <none>
azure-vote-front-6755d8b845-4rv2s 1/1 Running 0 1h 10.244.1.4 aks-nodepool1-
11483416-0 <none>
azure-vote-front-6755d8b845-bqbrk 1/1 Running 0 1h 10.244.1.5 aks-nodepool1-
11483416-0 <none>
azure-vote-front-6755d8b845-lq8gv 1/1 Running 0 1h 10.244.0.8 aks-nodepool1-
11483416-1 <none>
php-apache-8675c4f9d6-m5kwj 1/1 Running 0 57m 10.244.0.10 aks-nodepool1-
11483416-1 <none>
Podが動いているNodeを確認
Ready
Node 0と1に
Podが分散している

$ az vm list
Name ResourceGroup Location Zones
------------------------ --------------------------------------------------------- ---------- -------
aks-nodepool1-11483416-0 MC_TOMAKABE-AKS-HANDSON-RG_TOMAKABE-AKS-HANDSON_JAPANEAST japaneast
aks-nodepool1-11483416-1 MC_TOMAKABE-AKS-HANDSON-RG_TOMAKABE-AKS-HANDSON_JAPANEAST japaneast
$ az vm stop -g MC_tomakabe-aks-handson-rg_tomakabe-aks-handson_japaneast -n aks-nodepool1-11483416-1
$ kubectl get nodes
aks-nodepool1-11483416-1 NotReady agent 2h v1.11.3
NodeをVMレベルで止めてみましょう
どちらでも
構いません
NotReady

$ kubectl get pod -o wide
NOMINATED NODE
11483416-0 <none>
11483416-0 <none>
11483416-0 <none>
azure-vote-front-6755d8b845-kjjxf 1/1 Running 0 40s 10.244.1.14 aks-nodepool1-
11483416-0 <none>
azure-vote-front-6755d8b845-lq8gv 1/1 Unknown 0 2h 10.244.0.8 aks-nodepool1-
11483416-1 <none>
php-apache-8675c4f9d6-h7nc7 1/1 Running 0 40s 10.244.1.12 aks-nodepool1-
11483416-0 <none>
php-apache-8675c4f9d6-m5kwj 1/1 Unknown 0 1h 10.244.0.10 aks-nodepool1-
11483416-1 <none>
Podの状態を見てみましょう
停止Node上のPodは
Unknownに
別Nodeで再作
成

$ az vm start -g MC_tomakabe-aks-handson-rg_tomakabe-aks-handson_japaneast -n aks-nodepool1-11483416-1
$ kubectl get node
$ kubectl get pod -o wide
NOMINATED NODE
11483416-0 <none>
11483416-0 <none>
11483416-0 <none>
azure-vote-front-6755d8b845-kjjxf 1/1 Running 0 4m 10.244.1.14 aks-nodepool1-
11483416-0 <none>
php-apache-8675c4f9d6-h7nc7 1/1 Running 0 4m 10.244.1.12 aks-nodepool1-
11483416-0 <none>
Nodeの復帰
Readyに
Unknown Pod
は無くなる

おさらい
様々なリソース拡張手段 (Node/Pod、水平/垂直、自動/手動)
HPAは実際の利用状況を見てPodを自動増減する
Cluster AutoscalerはPendingのPodがあるとNodeを追加する
Nodeは定期的に状況をAPI Serverへ報告している
報告が途絶えるとNodeはNotReadyと判断され、Podが再作成される

Kubernetes アプリ開発応用
第3部

CI/CDパイプライン
Source
code control
Helm
chart
Inner loop
Azure
Container
Registry
Azure Pipeline/
DevOps Project
Auto-
build
Azure
Monitor
CI/CD
Test
Debug
Azure
DevSpaces
AKS dev
cluster
AKS production cluster
Pods
ACI instances
Pods
• 手作業でのコンテナーデプロイは
手間がかかるしリスクも高い
• コードのコミット、コンテナーの
ビルド、Kubernetesクラスターへ
のデプロイを自動化するパイプラ
インの構築は考慮したいテーマ

実装例: Azure DevOps CI/CDパイプライン
Azure Repo
Git互換リポジトリ
Azure Pipeline
パイプライン管理
Azure Container Registry
プライベートコンテナーレジストリ
Kubernetes
参考資料: チュートリアル: Azure DevOps プロジェクトを使用して ASP.NET Core アプリを Azure Kubernetes
Service (AKS) にデプロイする

Azure DevOpsによる
Kubernetes CI/CD パイプライン
デモ

$ az group delete -n PREFIX-aks-handson-rg
おつかれさまでした

参考資料
公式ドキュメント
Azure Kubernetes Service (AKS)
概要、チュートリアル、概念などが
まとまっています

半日でわかるコンテナー技術 (応用編)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 半日でわかるコンテナー技術 (応用編)

Semelhante a 半日でわかるコンテナー技術 (応用編) (20)

Mais de Toru Makabe

Mais de Toru Makabe (20)

Último

Último (9)