しくみがわかる azure kubernetes service (aks) ～ …...舞黒華子さんについて •...
Post on 03-Apr-2020
6 Views
Preview:
TRANSCRIPT
de:code 2019 CD06
しくみがわかる Azure Kubernetes Service ～開発者目線で Kubernetes の基本を理解する～
日本マイクロソフト株式会社
パートナー事業本部 パートナー技術統括本部
阿佐志保
2
本日お話しすること• 開発者が知っておきたいKubernetes の基本的なしくみ
（ Pod・ReplicaSet・Deployment ）
• コンテナアプリの開発経験がある方を想定 （L２００：初級者向け）
本日お話しすること
本日お話ししないこと• 一般的なコンテナ のメリットやデメリットについて
• マイクロサービス・Service Mesh など
• クラウドアーキテクト向けのインフラに関する情報について
• 開発組織や文化について
本日のゴールKubernetes の基本的なしくみを知り、使いどころを知ろう
すみません
とても緊張しています
舞黒華子さんについて
• 独立系ソフトウェア企業「株式会社 コントソ・テクノロジ」所属
言語はRuby Python Node.js など
ＧｉｔＨｕｂ やDocker を使っている
舞黒華子さんの最近の悩み
コンテナ化してポータビリティを高めたい
開発者フレンドリーなコンテナオーケストレーション基盤がほしい
継続的インテグレーション・継続的デリバリーを実現したい
こういう環境があるといいな
ソースコード
ビルドパイプライン
</>
コンテナイメージ アプリ
ソースコードリポジトリ
開発 デリバリー 運用
開発環境
ステージング環境
本番環境（AzureやGCPなど）
開発チームにて実施
インフラ管理者
リリースパイプライン
責任者による承認
自社開発したWeb アプリを
たくさんの人に使ってもらいたい
Kubernetes とは
コンテナとは
生い立ち
オンプレミスサーバコンテナイメージ
• アプリケーションの実行に必要なものを1つのイメージにまとめて任意の環境で稼働させるための技術
• アプリのポータビリティ向上 https://www.docker.com/
アプリ
Dockerfile
開発環境
Build&Ship
コンテナを分散環境で動かすのは難しい
負荷分散
ネットワーク管理
デプロイ
クライアントで利用
アップデート
分散環境で利用
コンテナを分散環境で運用するには、高度な知識とノウハウが必要
便利なツール！！
ストレージ管理
Kubernetes とは
• コミュニティで開発がすすめられているオープンソースのコンテナオーケストレーションツール
• GoogleやMicrosoft やRedHat のエンジニアも積極的に開発に参加！
さっそく、Kubernetes クラスタを構築しましょう！
• Prerequisites• Installing the Client Tools• Provisioning Compute Resources• Provisioning the CA and Generating TLS Certificates• Generating Kubernetes Configuration Files for Authentication• Generating the Data Encryption Config and Key• Bootstrapping the etcd Cluster• Bootstrapping the Kubernetes Control Plane• Bootstrapping the Kubernetes Worker Nodes• Configuring kubectl for Remote Access• Provisioning Pod Network Routes• Deploying the DNS Cluster Add-on• Smoke Test
https://github.com/ivanfioravanti/kubernetes-the-hard-way-on-azure
なるほ 、、、、 ど ？
Azure Kubernetes Service (AKS) とは
• Azure で Kubernetes クラスタを構築／管理できるマネージドサービス
• 定義した要件にもとづいてコンテナをクラスタに配置しオーケストレーションする
• 2018年6月に GA日本東西リージョンでも利用可
https://azure.microsoft.com/ja-jp/services/container-service/
自前Kubernetes
AKS
コンテナ化
アプリのイテレーションデバッグ
CI/CD
クラスタ作成
クラスタアップデート
スケーリング
モニタリング・ロギング
：ユーザ ：Azure
コマンドによるAKS クラスタの操作
$ az aks create -n $CLUSTERNAME -g $RGNAME ¥--kubernetes-version 1.12.4 ¥--service-principal $APPID ¥--client-secret $CLIENTSECRET ¥--generate-ssh-keys -l $LOCATION ¥--node-count 3 ¥--enable-addons monitoring
$ az aks upgrade -n $CLUSTERNAME -g $RGNAME ¥--kubernetes-version 1.12.8
• クラスタの構築
• クラスタのバージョンアップ
Node 3
Master -管理ノード
Node 1 Node 2
Kubernetes
1.12.4
Kubernetes
1.12.8
アプリをKubernetesで動かそう
Kubernetesはじめの一歩
Node（ノード）• コンテナをデプロイするサーバマシン(Azure VM)• 複数のNodeをまとめたものがクラスタ
Kubernetes クラスタ
Node１（Azure VM）
クラスタを管理
Master
Node2（Azure VM）
NodeN（Azure VM）
Webコンテナ
プロキシコンテナ
Pod（ポッド）• 1個以上のコンテナの集合体• Pod 内のコンテナは 仮想 NIC・ Volume を共有
同じNode上にデプロイ• Pod 単位でコンテナの作成／開始／停止／削除
Pod
どのようなPodを起動したいかをファイルに定義
name: Podの名前
label: 識別のためのラベル
image: イメージのレジストリ
port: 転送するポート番号
# 基本項目
apiVersion: v1
kind: Pod
metadata:
name: service-tracker-ui # Podの名前
labels: # Podのラベル
app: service-tracker-ui
# Podのスペック
spec:
# コンテナの仕様
containers:
- image: xxx.azureacr.io/image:1.0
name: containername
ports:
- containerPort: 80
Pod の起動はkubectl コマンドで
$ kubectl apply –f pod-sample.yaml
# 基本項目
apiVersion: v1
kind: Pod
metadata:
name: service-tracker-ui # Podの名前
labels: # Podのラベル
app: service-tracker-ui
# Podのスペック
spec:
# コンテナの仕様
containers:
- image: xxx.azurecr.io/image:1.0
name: containername
ports:
- containerPort: 80
のMaster に
ｋubectlコマンドの裏側
API Server
kubelet
Master
etcd
クラスタ構成情報
docker
Node１ Node 2 Node N
$ kubectl apply ↩
apiVersion: v1
kind: Pod
metadata:
name: data-api
labels:
app: data-api
spec: kubelet
docker
kubelet
docker
REST
①構成情報をクラスタに送信 apiVersion: v1
kind: Podmetadata:
name: data-apilabels:
app: data-apispec:
② etcd の情報を更新
Pod ③構成情報に従いPod作成
Podデザインパターン
サイドカーパターン
アンバサダパターン
アダプタパターン
参考：分散システムデザインパターンhttps://www.oreilly.co.jp/books/9784873118758/
メインコンテナ
ログ送信
ロギングサービスへ
Sidecar コンテナ
log
アプリA アダプタ
アプリB アダプタ
アプリコンテナ
DB接続
DBへ
プロキシ
localhost
共通インターフェース
Podを作成する重要なポイント！
同じNode で実行する必要があるかどうか
同じタイミングでスケールする必要があるかどうか
Webアプリコンテナ
OAuthコンテナ
リクエストの認証処理
Webアプリコンテナ
SSLプロキシコンテナ
https://www.hoge.com/
http://localhost/
フロントエンドコンテナ
バックエンドコンテナ
アクセス急増
Best Practicesfor Developers👉
Podが動いているかどうかを確認するには？
LivenessProbe• プロセスの死活監視
• Pod が正常に動作しているかのチェック
• 正常でない場合、Pod を再起動
ReadinessProbe• ロードバランサからの死活監視
• アプリが応答するかどうかのチェック
• 正常でない場合、トラフィックを流さない
Kubernetes はアプリに対するヘルスチェックのしくみがある
引用：しくみがわかるKubernetes
Podのヘルスチェックのタイミングは？
initialDelaySeconds• Kubernetes がPod の監視を始めるまでの時間
periodSeconds• 監視間隔
containers:
- name: liveness
image: k8s.gcr.io/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: X-Custom-Header
value: Awesome
initialDelaySeconds: 10
periodSeconds: 5
引用：しくみがわかるKubernetes
アプリで使うデータベースの接続文字列
API キーなどの秘匿情報
どうするの？
ConfigMap と Seclets
CofigMapアプリの設定情報をクラスタ内で保持
• Key-Value または 設定ファイル
• コンテナからは ① 環境変数として渡す② Volume マウント
Master
etcd
クラスタ構成情報
Node１
ID = *****Pass = *****
Pod
connectionString = abcde
Seclets
ConfigMap
Node2 NodeN
Secretsアプリの機密情報をクラスタ内で保持ユーザID ／パスワード／証明書／秘密鍵など
• Key-Value または 設定ファイル
• Base64でエンコード（暗号化ではない）
• tmpfs領域に展開される
もし、アプリが暴走してしまったら・・・
Kubernetes クラスタでは複数のアプリが共存
Kubernetesクラスタ
Node１ Node２ NodeN
Podコンピューティングリソースは有限
うるさい隣人問題
コンテナが使用するCPU／メモリの設定
• Resource Limits
• Resource Requests
どちらも設定しましょう ！
コンテナ
Resource Limits実際の使用量が・ CPU ５00m・ メモリ ２Giを超えたらkillしてね
Resource Requestsデプロイするときに・ CPU 400m
・ メモリ 1Giを確保してください
Demo ～ Request Limit メモリに上限を設定した場合～
Kubernetes のしくみ
Pod はクラスタ内のどこにデプロイされるの？
どうやってきまるの？
Kubernetesのスケジューリング
従来の方式
フロントエンドアプリ
バックエンドアプリ
フロントエンドアプリ
Kubernetes の場合
Kubernetes クラスタ
Node１ Node２ NodeN
Pod
スケジューリングのアルゴリズム
• Nodeフィルタリング
• Nodeの優先度
https://github.com/kubernetes/community/blob/master/contrib
utors/devel/sig-scheduling/scheduler_algorithm.md
Scheduler Algorithm in Kubernetes
スケジューリングのしくみ
API Server
Scheduler
Master
etcd
クラスタ構成情報
Node１ Node 2 Node N検知
$ kubectl apply ↩
① コマンド実行
Pod を1つ
② Pod の構成情報を更新
検知
③ Pod を割り当てるNode の選定
kubelet
docker
kubelet
docker
kubelet
docker
検知
⑤ Podを生成
Node2 に配置だ！
④ Node情報を更新
Kubernetes、障害があったとき
自動復旧できると聞きました ！
ReplicaSet とは
• Pod を指定の数だけ維持するしくみ
• コンテナが異常停止したら該当 Pod を削除して新たな Pod を自動で起動
• Pod の再起動ではない
Kubernetes クラスタ
Node１ Node２ NodeN
Pod の数 ＝ ５
Demo ～ ReplicaSet によるPodの自己修復 ～
めっちゃ、大事なことを言います
Kubernetesの宣言的設定
Kubernetes のマニフェストは、クラスタのあるべき姿を定義したもの
Kubernetes のコンポーネントが変化を検知し
システム（≠人間）がつねにあるべき姿になるよう維持する
命令的設定
1. 障害検知2. エラー修復3. 再起動など
コマンド実行
オンプレサーバ仮想マシン
バックエンドアプリ
手順書
常にクラスタ内でPodは全部で5つ起動していること
状態を常に監視
Kubernetes クラスタ
宣言的設定
マニフェストファイル
障害を自動で復旧
Level Triggering とは
Level Triggering
Edge Triggering
Reconciliation loop とは
1. あるべき姿を知る
2. 現在の状態を監視する
3. あるべき姿と現在の状態の差分をとる
4. あるべき姿になるよう処理を実行
•
ユーザが宣言した望ましい状態
現在のシステムの状態
Reconciliationloop
監視
必要なアクション
Kubernetesの内部アーキテクチャ
User
Node
Docker
Prod Prod
Node
Docker
Prod Prod
Master
API server
API ServerKubernetes のリソース情報を管理するためのフロントエンドのREST API
Containers Containers Containers Containers
kube-proxykubelet kube-proxy kubelet
Internet
KubeletNode でコンテナを実行したりストレージをマウントする機能
KubeproxyNode で動作するプロキシ
Scheduler
SchedulerPod をどのNode で動かすかを制御するためのコンポーネン ト
Controller Manager
Controller ManagerKubernetes クラスタの状態を監視しあるべき状態を維持するコンポーネント
etcd
etcdクラスタの構成を保持する分散KVS
分散システムでは
つねにシステムのどこかが壊れている前提で
アプリケーションを開発する
アプリのバージョン管理
アプリのバージョンアップ戦略
アップデート前
ローリングアップデート
アップデート後
新旧のアプリケーションのアクセス先を切り替える
ブルーグリーンデプロイメント
新旧のアプリケーションを少しずつ入れ替える
Ｄｅｐｌｏｙｍｅｎｔ とは
• ＲｅｐｌｉｃａＳｅｔ のバージョンを管理するしくみ
• ローリングアップデートやロールバックなどができる
• Pod テンプレート内を更新したときのみロールアウト
• Pod/ReplicaSetではなくDeploymentの使用をおすすめ
apiVersion: apps/v1
kind: Deployment
metadata:
name: tracker-ui
spec:
replicas: 5
selector:
matchLabels:
app: tracker-ui
template:
metadata:
labels:
app: tracker-ui
spec:
containers:
- image: x.azurecr.io/x/tracker-ui:1.0
Deployment
ReplicaSet
Deployment
ReplicaSet v1 ReplicaSet v2 ReplicaSet v2
Deployment
Strategy ＝ ローリングアップデート
V1.0 V2.0
旧 ＲｅｐｌｉｃａＳｅｔ 新 ＲｅｐｌｉｃａＳｅｔ
Flight
Podテンプレート
セレクタ＝
レプリカ数 ＝ 10
Flight
マニフェストのデータ構造を理解する
Pod
コンテナのスペック
Flight
Podテンプレート
ReplicaSet Deployment
リソースの役割や内部のしくみを頭に入れておくとすっきりする
コンテナの仕様 コンテナの数 コンテナのバージョン
Tips for Developers👉
オートスケールのしくみ
Kubernetesでのスケーラビリティ
Horizontal Pod Autoscaler（HPA） Vertical Pod Autoscaler（VPA）
クラスタ
Node Node
水平スケール 垂直スケール
Node Node Node Node
Pod のスケール
Node のスケール
クラスタ
（新たな課金が必要）
Kubernetes
Azure
Up
Up
Podの数を負荷に応じて自動で増やしたい
Horizontal Pod Autoscaler (HPA)
• CPU負荷などに応じてPodを自動でスケールする機能
• PodのResource Requestの設定が必要
• Kubernetes内のmetric-serveが取得したメトリックの1分間の平均から必要なPod数を計算
• レプリカの最大と最小を設定できる
# (1) 基本項目
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: budy-hpa
# (2) HPAのスペック
spec:
minReplicas: 1 # 最小レプリカ数
maxReplicas: 5 # 最大レプリカ数
# スケールする条件
metrics:
- resource:
name: cpu
targetAverageUtilization: 30
# CPUが30%になるよう調整
Horizontal Pod Autoscaler（HPA）のしくみ
API Server
Master
Node１ Node 2 Node N
kubelet kubelet kubelet
HPAController
Podは3つ必要
① メトリックをもとに必要なPod数を計算
Poｄ数＝PodのCPU使用率の合計／targetAverageUtilization
metricserver
ReplicaSetController
②指定されたPod数をになるよう調整
New
イベントをもとにKubernetes をスケーリングさせるオープンソースプロジェクト
対応しているイベント（２０１９/０５）
•Kafka•RabbitMQ•Azure Storage Queues•Azure Service Bus Queues and Topics
対応計画中のイベント•Azure Event Hubs•Prometheus•Azure Storage Blobs
New
https://github.com/kedacore/keda
Metric Adapter• キューの長さやストリームの遅延などのイベント関連データを通知
Scaler• イベントをトリガーに 0<1 または １＞０ のスケールアップとスケールダウンを行う
apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
spec:
scaleTargetRef:
deploymentName: twitter-function
triggers:
- type: kafka
metadata:
type: kafkaTrigger
topic: twitter
Demo ～ KEDAによるPodのスケール～
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-kubernetes-keda
Kubernetes は
なぜ、生まれたの？
これがあると、楽なんだけどなぁ
コンテナアプリ
CPUもメモリも無限にあるとまらないサーバ-
デプロイ
コンテナアプリ
コンテナアプリ
コンテナアプリ
ほっといてもいい感じで
アプリを動かしてくれるなにか
Kubernetesが目指すもの
コンテナアプリ
デプロイ
複数のマシンをあたかも
1台のように！ コンテナアプリ
管理ノード
ノード１ ノード2 ノードn
Kubernetesクラスタ
コンテナアプリ
コンテナアプリ
https://www.oreilly.com/library/view/kubernetes-up-and/9781491935668/
Kubernetes: Up and Running:
その技術が本質的に
どのような課題を解決するのか
それを知るには
しくみを理解するのが近道（ 道具の使いどころを間違えにくい ）
バッチジョブを実行したいjob / cronjob
ステートフルアプリを動かしたいStatefulSet
Nodeで必ずアプリを１つ動かしたいDaemonSet
ロードバランサを動かしたいＳｅｒｖｉｃｅ / Ｉｎｇｒｅｓｓ
Kubernetesにはたくさんの機能があります必要なものをチョイスして利用するのがおすすめ
永続データを扱いたいParsistentVolume
リソースに制限をかけたいResourceQuota
サービスのためのアカウントが必要ServiceAccount
RBACを行いたいRole/ RoleBinding
公式マニュアルや書籍、技術ブログにたくさん情報がありますhttps://kubernetes.io/
コンテナを案件で利用するには業務システムで考慮すべき主なポイントを、クイックに
要件 内容例
可用性 回復性、稼働率、RTO(目標復旧時間) 、RPO(回復ポイント目標)
性能・拡張性 ユーザ数、RPS、目標レスポンス速度、成長に応じた拡張
運用保守性 バックアップ、計画停止、運用監視、障害時対応、運用自動化
移行性 移行時期、並行稼働有無、システム展開方式、移行データ量
セキュリティ コンプライアンス、リスク分析、通信制御、認証、不正検知・追跡・監視
情報処理推進機構（IPA）の非機能要件グレード 非機能項目（大項目）と、内容例
ご参考：システムに求められる非機能要件
参考：しくみがわかるKubernetes 第9章
https://www.shoeisha.co.jp/book/detail/9784798157849
https://www.slideshare.net/ToruMakabe/kubernetes-120907020
クラスタのNode数を増やしたい
Cluster Autoscaler• リソースの制約でスケジュールできない
Pod を監視し、Node の数を自動で増やす機能
• HPA と連動して動作させることも可• VMSS を使用し、かつ Kubernetes
1.12.4 以降が必要
$ az aks create -n $CLUSTERNAME -g $RGNAME ¥--kubernetes-version 1.12.8 ¥--node-count 3 ¥--enable-vmss ¥--enable-cluster-autoscaler ¥--min-count 1 ¥--max-count 3
参考：しくみがわかるKubernetes 第9章
https://www.shoeisha.co.jp/book/detail/9784798157849
NodePool• 同じ構成（SKU）のノードをグループ化してプールする機能
• 利用例としては、コンピューティング集約型のPod に GPU を提供したいときなど
az aks nodepool upgrade ¥-n $CLUSTERNAME -g $RGNAME ¥--name gpunodepool ¥--kubernetes-version 1.12.8
Preview
Preview
https://docs.microsoft.com/ja-jp/azure/aks/cluster-autoscaler
https://docs.microsoft.com/ja-jp/azure/aks/use-multiple-node-pools
Node Node
Master
Azure Container Instances (ACI)
ACI とは
https://github.com/virtual-kubelet/virtual-kubelet
Preview
Node
https://docs.microsoft.com/ja-jp/azure/azure-monitor/insights/container-insights-overview
Demo ～Azure Monitor for Containersによる監視～
Preview
https://docs.microsoft.com/ja-jp/azure/aks/use-pod-security-policies
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: psp-deny-privileged
spec:
privileged: false
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
volumes:
- '*'
New
クラウドアーキテクト
Cluster-1 Cluster-2 Cluster-3
Cluster-3
Cluster-2Cluster-1
コンプライアンスレポート
クラスタにポリシーを割り当て
ポリシーとフィードバック
Podレベルでのコンプライアンスレポート
開発者AKS
Azure Policy
https://www.youtube.com/watch?v=QG1hOasct0M
Source code
Azure Pipelines
Build
Azure Pipelines
Release
Kubernetescluster
Azure Monitor
</>
コンテナイメージ Pod
ソースコードリポジトリ
Azure Pipelines for AKS
開発 デリバリー 運用
https://azure.microsoft.com/ja-jp/services/devops/pipelines/
New
Demo ～ Azure Pipelines によるビルド・デプロイの実行～
Demo ～ Azure Pipelines for AKS YAMLによるパイプライン記述～
Azure Kubernetes エコシステムをうまく連携して利用するとよい
https://github.com/Azure/AKS/projects/1https://azure.microsoft.com/mediahandler/files/resourcefiles/kubernetes
-learning-path/Kubernetes%20Learning%20Path%20version%201.0.pdf
Microsoft との協業パートナーネットワークと Azure Marketplace
自社開発したWeb アプリを
たくさんの人に使ってもらいたい
システムのスケーラビリティ
＋
ビジネスのスケーラビリティ
マイクロソフトとの共同販売
マーケットプレース
販売パートナー
インサイドセールス
対面営業
https://azuremarketplace.microsoft.com/ja-jp/
OS
セキュリティ / IDネットワーク
データ + 分析
ストレージ/バックアップ、災害対策
DevOps管理/コンテナ
コンサル サービスBlue GraniteWipro Unify CloudXcent Bright WolfDecisive Data Dynamics Edge ConvergenceVNB Consulting
GitHubBitnami DockerChef MesosphereJenkins Puppet TerraformOpenShift
NetAppCloudEndure DellEMCCommVault VeeamSoftNAS Veritas HPEZerto
HortonworksCloudera ElasticDatastax QuboleInformatica Splunk TeradataTableau
CitrixAqua Check PointBarracuda F5Cisco Fortinet SophosPalo Alto Networks
SuseCentOS RedHatDebian Ubuntu
本日お話しすること
• Kubernetes は難しい、しかし分散システムを学ぶには良い教材
• しくみを理解し、実際に手を動かすことで、どこでどう使えばよいかが見えてくる
• 業務システムで利用するときは、クラウドのサービスを上手に利用するとよい
• Kubernetes に限らず「システムで何を実現したいか」の本質を常に忘れずに
Enjoy！
本日お話しすること
9:30 /14:50 (Room H )
[CD65] AKS で Kubernetes を構築してスケーラブルなアプリケーションをデプロイしてみよう！
10:50 (Room E)
[CD02] Azure Functions 2.0 Deep Dive -デベロッパーのための最新開発ガイド
13:10 (EXPO Open Theater 2)
[CD93] コンテナ環境の永続化ストレージ問題を NetApp Kubernetes Service と Azure NetApp Files でさらっと解決
13:40 (Room F)
[DT04] ここでしか聞けないマイクロサービス on AKS 導入のなま苦労話 by オイシックス・ラ・大地
16:40 (Room F)
[CD12] マネージド Kubernetes ガチ本番運用 in ZOZOTOWN
16:10 (Room L)
[CD08] Enterprise Open Source on Azure が開発者の生産性を最大化できる 3 つの理由
© 2018 Microsoft Corporation. All rights reserved.
本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。
© 2019 Microsoft Corporation. All rights reserved.
本情報の内容 (添付文書、リンク先などを含む) は、de:code 2019 開催日 (2019年5月29~30日) 時点のものであり、予告なく変更される場合があります。
本コンテンツの著作権、および本コンテンツ中に出てくる商標権、団体名、ロゴ、製品、サービスなどはそれぞれ、各権利保有者に帰属します。
top related