『Kubernetesで実践するクラウドネイティブDevOps』学習メモ
Ch01 Cloud Revolution
目的
- 3つの革命
- クラウドの創造
- DevOps
- コンテナ
- → Cloud Native with OS:Kubernetes
- revolutionのhistory, 重要性を見て，ソフトウェア deliveryへの作用を考える
- 想定される変化
- Cloud Native DevOpsがtheme
概要
- (1) クラウド
- 処理能力を買う
- SaaS
- Iaas
- Undifferentiated Heavy Lifting(UHL)
- (2) DevOps
- (3) コンテナ
- 依存関係, config
- history, background
- Puppet, AnsibleなどのConfig Management System
- omnibus package
- VM Image
- 問題多い（コスト，不安定）
- 特性: 可搬容量，コストdown, 規模の経済，扱いやすさ
- イメージ fileをコンテナ runtimeで実行
- 仮想化による実行効率downの解決 with real CPU
- file システムのlayerをaddress指定
- → コンテナ間でlayerの共有や再利用〇
- コンテナは再利用の単位
- scalingの単位，リソース配分の単位でもある
- コンテナが依存するのは唯一OSのkernelのみ
- Kubernetes
- history @ Borg
- コンテナをserverのpoolで実行するための割り当てとschedulingを行う集中管理システム
- history @ Borg
- values
- Kubernetesによる従来のシステム 管理 taskのautomate
- デプロイの容易さ
- zero down time デプロイ with Rolling Update
- canaria デプロイ, bluegreen デプロイ in Continuous デプロイ
- auto scale
- 冗長性とfail overでの信頼性と耐障害性up
- cost down by 能力の浪費cut
- クラウド providerと疎である by Kubernetesの抽象化
- コンテナはソフトウェアを定義するための可搬性の方法 & Kubernetes リソースはソフトウェアの実行方法の可搬性のための方法
- Kubernetesの制約
- DBなどのステートフルなworkloadへのcost 大
- → 代わりにmanaged serviceを使用
- Faas, (server served platform). e.g. AWS Lambda
- functionとコンテナのhybrid: Funtainer
- → Knative
- (4) クラウドネイティブ
- 一般的用法: クラウド, コンテナ, orchestrationを活用し，多くの場合OSSをbaseとする，最先端アプリケーションやserviceを簡潔に表現する手段．
- 自動化されたInfrastructure as Code
- 特性
- automate可能
- Ubiquitous and flexible
- resilient(弾力的) and scalable
- dynamic
- Obserbable
- distribution: 分散化，非集中化
- codeを単一のentity(monolithus)としてデプロイ
- or multi 分散 micro servicesで構成
- micro server: 1つのことを実行する自己完結型service
- monolithusの方が理解しやすく，相互作用を追跡できる
- but, monolithusは拡張difficult
- 一般的用法: クラウド, コンテナ, orchestrationを活用し，多くの場合OSSをbaseとする，最先端アプリケーションやserviceを簡潔に表現する手段．
作用
- 運用の観点
- Developer Productivity Engineering(Developer生産性工学), DPE team
- Site Reliability Engineering(SRE)
- Kubernetesの重要性 pointsのまとめ
Ch02 Kubernetes first step
概要
- Docker
- Dockerは複数で異なる but 関連する要素から成る
- コンテナ イメージ format
- コンテナ run time library
- コンテナのlifecycleの管理
- command line tool
- コンテナ 管理用API
- コンテナ イメージ: ZIP fileのようなもの
- 実行のためには，ID or URLを指定するだけ
詳細
(1) コンテナ build
- docker image build with Dockerfile
- Dockerfile specifies all what イメージ has to have
- 既存のイメージ(: base イメージ)にもとづいて新しいイメージをbuild
- multi stage build
- scratch イメージにbuilded binaryをcopy → 軽量化， attack surface(攻撃対象領域)の縮小
- -tによるtagづけ
portの転送
''' -p HOST_PORT:CONTAINER_PORT '''
- docker image build with Dockerfile
(2) コンテナ Registry
- Docker IDをgetし，Docker Hubにオリジナル イメージをpush
- イメージの命名とpush
- → どこからでもコンテナ イメージを実行可能
- (3) Kubernetes
- Enable Kubernetes @Docker Desktop
- demo アプリケーションの実行
- deploymentのcreate
- port forward
- (4) Minikube
まとめ
- コンテナをbuild and runの実践
- Kubernetes環境の確率
Ch03 Kubernetes 環境の選択
目的
- クラスタのbasical structureの理解
- Kubernetesの実行方法を決定するための情報
- managed serviceの長短
概要
- クラスタのarchitecture
- Kubernetesがmulti serverを接続して1つのクラスタとする
- controll plain
- このcomponentを実行するメンバ（ノード）: master ノード
- kube-apiserver
- etcd: DB
- kube-scheduler
- kube-controller-manager
- クラウド-controller-manager
- ノードのcomponent @Worker ノード
- kubelet
- kube-proxy
- コンテナ runtime
- 高可用性
- network partitionも処理〇
- controll platformの高可用性の重要性
- quorumを維持
- e.g. 本番クラスタは3つが最小
- quorumを維持
- multi availability zoneへの分散
- testの実施が重要
詳細
- (1) self hosting Kubernetesのcost
- buy or build
- cost 大．engineerの給与約100万ドル
- 初期セットアップから稼働を通してcareが必要
- まずはmanaged service
- (2) managed Kubernetes services
- GKE
- 高可用性
- multi zone/ regional クラスタ
- auto scale
- 高可用性
- EKS
- 後発＆割高
- AKS
- OpenShift: PaaS
- IBM Cloud Kubernetes サービス
- HKs
- GKE
- (3) turnkey方式のKubernetes solution
- (4) Kubernetes installer
- kops @AWS
- Kubespray with on-premised install & bare(何も導入されていない) metal server
- TK8 with Terraform and Kubespray
- Kubernetes The Hard Way: 教育に◎
- kubeadm: Kubernetesのinstallに◎
- Tarmak: 変更をノード 設定にrolloutする処理の迅速性と安全性up
- RKE: simple & high-speed
- Puppet Kubernetes module
- Kubeformation: 既存のautomate toolのwrapper
- (5) 原則
- running ソフトウェアを減らす
- standard technologyのuse
- cost 大のタスクはoutsource
- 長寿の競争優位
- → managed Kubernetesの推奨
- クラウドネイティブ: 差別化につながらない要素をoutsourceしビジネスを加速
- self-hostingならkops, Kubespray
- 限られた予算 e.g. Raspberry Pi
- running ソフトウェアを減らす
- (6) clusterless コンテナ service
- Amazon Fargate, ACI
まとめ
- Kubernetes クラスタをservice providerに任せ，確実性と経済性を得る
Ch04 Kubernetes objectの基本操作
目的
- Kubernetesの基本object: Pod, Deployment, サービス + Helm tool
概要
- (1) Deployment
- Superviserの機能 @Kubernetes
- 個々のプログラムに対応
- Deployment Objectを作成
- Deployment controllerによる制御
- Default: コンテナのrestart
- Deployment 情報 get command
- (2) Pod
- 1つ以上のコンテナのグループ ← クジラの群れ
- Podの仕様(spec: specification)のcontainers list
- kubectl run: Deploymentを作成 → DeploymentがPodを起動
- Deployment: 「あるコンテナを持つPodを1つ実行し続ける必要がある」といった，望ましい状態の宣言
- (3) ReplicaSet
- Deployment-ReplicaSet-Pod
- ReplicaSet controllerが必要な数（同一）のPod,ReplicaSetのグループを管理
- → DeploymentがReplicaSetを管理: ユーザのReplicaSetのupdateをcontroll
詳細
- (1) Keep desirable state
- 調整loop
- Deploymentのshutdown
- 調整loop
- (2) Kubernetes scheduler
- DeploymentがKubernetes DBにPod リソースを作成 & Pod into cueue
- → schedulerがPodを取り出してrunnabeなノードを見つける
- ⇔ Podをノードにscheduling
- → kubeletがPodが含むコンテナを起動
- DeploymentがKubernetes DBにPod リソースを作成 & Pod into cueue
- (3) YAML形式のリソース manifest
- Kubernetesは本質的に宣言的
- → continuous reconcliation(調整; cal-, -cli-: 呼び集める)
- → specを変更すればKubernetesが処理してくれる．
- DeploymentやPodなどのKubernetesのリソースはすべて内部のDBのrecordで表現
- 「kubectl run」でnew recordをinsert or 「リソースのmanifestを読み取るよう指示」
- コンテナ イメージの名前とPortが重要
- @DeploymentのYAML Manifest
- ↑→ kubectl runで指定していた
- kubectl applyでmanifestをクラスタに送信
- サービス リソース
- 単一の変化しないIP address or DNSnameを付与
- → 対応するPodへ自動ルーティング
- → Podにnetwork経由でconnect
- Web proxyやload balancerのようなもの
- backendのPodのグループにリクエストを転送
- 単一の変化しないIP address or DNSnameを付与
- サービスのYAML Manifest
- multi Pod → load balance
- 後始末 kubectl delete -f Kubernetes/.
- Manifestのdirectoryをdelete
- kubectlでのクラスタへのquery
- kubectl get
- kubectl describe pod/dem-dev-6c...
- YAML Manifestでの宣言的デプロイにおける繰り返しの解消 → Helm
- Kubernetesは本質的に宣言的
- (4) Helm: Kubernetes package manager
- command line toolでDeployment リソースとサービスをHelmが作成．
- アプリケーションをinstall and configure
- chart: real コンテナ イメージを含まないyaml manifestのwrapper.同じクラスタ内に何度もinstall可能
- アプリケーションをKubernetesで実行するために必要なリソースの定義がすべて格納されるHelm package
- repository: chartの収集と共有
- release: Kubernetes クラスタで実行されるchartの特定のinstance
- helm install -name
- helm list, helm status
- command line toolでDeployment リソースとサービスをHelmが作成．
作用
- 何ができるかを理解
- ↑ PodやDeploymentのメカニズム
Ch05 リソース 管理
目的
- クラスタの最大活用
- リソースの使用状況の管理と最適化など
概要
- リソースの理解
- Kubernetes schedulerの観点
- Podが求めるリソースの量を把握
- リソースの単位: CPU, milliCPU, MiB@memory
- リソース要求: min
- リソース制限: max
- over commit〇: ノードのリソース総量を超えた制限可能
- コンテナのminimize
- Kubernetes schedulerの観点
詳細
- (1) コンテナ lifecycle 管理
- Liveness probe by HTTP
- Probeの遅延と頻度
- death loopの回避
- initialDelaySeconds, periodSeconds
- ほかのtypeのProbe
- TCP, gRPC
- Readiness Probe: 「一時的にリクエスト処理不可能」を知らせる． → 常に「200 OK」を返す必要
- zero downtime upgradeにeffective
- file based Readiness Probe
- minReadySeconds
- Pod Disruption Budget: 失ってもよいPodの数
- minAvailable, maxUnavailable
- (2) Namespace
- (3) クラスタ cost optimize
- Deploymentのoptimize
- serviceが求める処理能力と可用性のビジネス要件
- その要件より少なく達成できるか
- Podのoptimize
- normal 運用のmax + α → リソースのPackman状態の回避
- Vertical Pod Autoscalar
- Nodeのoptimize
- 観察
- 典型的なPodをat least 5個実行数rのに十分なサイズ
- stranded リソース(残されたリソース)の割合をunder 10%
- 10個いじょうなら5%
- Storageのoptimize
- I/O operation 毎秒(IOPS)で観察
- 未使用リソースのclean up
- kubeletのgarbage collection設定を調整
- 所有者metadata Annotationを使用し，Annotationのないリソースを強制終了候補にする
- ↑ すべてのリソースに所有者Annotationを設定
- 使用率が低いリソースの発見
- 受信リクエストの数をPodがメトリクスとして公開
- Web コンソールで各PodのCPUとメモリの使用率の数値をチェック
- finished jobのclean up
- 余剰capacityのcheck
- reserved instanceのuseでのcost down
- preemptive (spot) instance
- preemptive ノードはクラスタ全体の2/3以下にする
- ノード affinityでpreemptive ノードへのscheduling制御
- Kubernetes scheduler: workloadを多くのノードに均等にassign & replicaを異なるノードにおいて高可用性
- schedulerはノード間でPodを移動しない．
- → Deschedulerというtoolでのmove
- schedulerはノード間でPodを移動しない．
- Deploymentのoptimize
Ch06 クラスタの運用
概要
- (1) クラスタのsizingとscaling
- (2) 適合性チェック
- test suite がKubernetesにある
- CNCF認定: Certified Kubernetes, CKA, KCSP
- Sonobuoyでの独自クラスタのtest or managed service
- Sonobuoy Scanner
- (3) 検証と監査
- tool
- (kubernete Guard: Kubernetes クラスタのcommon 問題 check)
- Copper / instrumenta / Conftest
- kube-bench: 不要なことも多い
- Kubernetesの監査logging
- tool
- (4) Chaos Test
- Chaos Monkey Test
- 自動化と継続
- chaos kube
- kube-monkey
- powerful Seal
- → 高可用性を保証
Ch07 Kubernetes's tools
目的
- Kubernetesの作業のためのtoolやutility
- kubectlの高度な使い方と便利なutility
概要
- (1) kubectl
- shell alias
- @.bash_profile: alias k=kubectl
- flagの短縮形のuse
- リソース typeの省略
- kubectlでの自動補完 + aliasでの自動補完
- helpの表示: kubectl -h
- Objectのhelp: kubectl explain {pods, RESOURCE.FIELD, --recursive}
- 詳細な出力の表示
- kubectl get pods -o wide
- JSON形式の出力とjqなどでのfilter (→ jqのinstall)
- or JSON Pathでのquery
- Objectのsupervise: kubectl get pods --watch
- kubectl describe pods demo-xxx・・・
- shell alias
- (2) リソースを使った作業
- (3) コンテナを使う作業
- log: コンテナがstandard output or standard error outputのstreamに書くものすべて
- logの閲覧: kubectl logs -n kube-システム --tail=20 --follow(-f) etcd-docker・・・
- → supervise continuous output
- --tail/--since/--timestamps
- コンテナへのattach
- KubesprayでのKubernetes リソースの監視
- コンテナ Portの転送: kubectl port-forward
- コンテナでのcommand execution: kubectl exec
- debugのためのコンテナ実行
- kubectl run NAME --イメージ=IMAGE --rm(→del after completed) --it(i: 対話型, t: terminal) --restart=Never --command --・・・
- BusyBox(BB) commandの仕様
- 対話型のshell in クラスタ + shell alias → bb
- BBのコンテナへの追加
- BBはたった1MiB
- DockerfileでCOPY --from 命令
- → kubectl exec -it POD_NAME /bin/busybox sh
- コンテナへのプログラムのinstall
- kubesquashでのlive debug(本格的debugger)
- debuggerをコンテナにアタッチ: kubesquash
- with goのdebugger: dlv
- (4) ContextとNamespace
- Context: クラスタ, ユーザ, Namespaceの組み合わせ
- → bookmarkになる
- kubectl: 今のContext
- kubectl config get-context
- kubectxとbubensでContext切り替え高速化
- kube-ps1で現在のContextをpromptに追加
- → [( )]
- Context: クラスタ, ユーザ, Namespaceの組み合わせ
- (5) Kubernetesのshellとtool
- kube-shell: 補完のpopup
- Click: 対話型kubectl
- kubed-sh: クラスタ自体の上でプログラムを実行
- Stern: log
- (6) オリジナル Kubernetes toolの構築
- client-goでkubectlができるすべてを実現
作用
- kubectlで必要なことは何でもできる
Ch08 コンテナの実行
目的
- ~Ch07: 運用
- Ch08: 最も基礎的なObject in Kubernetes: コンテナ
概要
- (1) コンテナとPod
- Pod: Kubernetesでの{minimum デプロイ, schedule}単位
- Pod Objectが{単一/複数のグループ} コンテナを表す
- Kubernetesのすべての実行はPodを使用する
- 同じ実行環境上のアプリケーション コンテナ + storage volumeの集まり
- 1つのPod内のコンテナはすべて同じマシン上に配置
- コンテナ: 1つのソフトウェア, 依存関係, config, データなど，実行に関するものすべて
- 実行の担保はプロセス
- プロセス: 実行するアプリケーションのbinary codeとmemory statusを表現し，同じglobalなNamespaceに存在
- → プロセス間のやり取り〇．同じリソースのpoolを共有
- プロセス: 実行するアプリケーションのbinary codeとmemory statusを表現し，同じglobalなNamespaceに存在
- コンテナ: オリジナル Namespace内にある分離されたプロセス(のグループ)を表現する
- コンテナの内外ではプロセスは隠れる
- 実行の担保はプロセス
- コンテナの構成要素
- Podの構成要素
- Pod: 相互に通信してデータを共有する必要がある
- コンテナのグループを表現
- ともにschedule. 起動終了も同時．同じ物理マシン上で実行
- ⇔ 常に同じノード上で実行
- 異なるマシンで動作しないコンテナをPodでグループ化する
- Pod: 相互に通信してデータを共有する必要がある
- Pod: Kubernetesでの{minimum デプロイ, schedule}単位
- (2) コンテナのManifest
- 複数のコンテナsのtemplate spec
- name, イメージ
- イメージ識別子
- registry hostname, repository Namespace, イメージ repository, tagの4つで構成
- tagの例
- latest tag
- default: latest e.g. alpine:latest
- 本番環境ではlatestは×
- コンテナのdigestで決定的デプロイ
- ←→ tagでの非決定的デプロイ
- base イメージのtag
- 特定のtag/ digestのuse
- Port: Kubernetes上には意味なし．しかし，Manifestには含める
- リソース要求制限
- イメージのpullについてのpolicy: imagePullPolicy
- 基本はIfNotPresent
- 環境変数の設定
- 複数のコンテナsのtemplate spec
- (3) コンテナのSecurity
- principle of least privilege
- bug riskのminimize
- 一般ユーザの割り当て: runAsUser
- UID 1000: first not root ユーザ
- security maximize: コンテナごとのUID
- データを共有するためのアクセス: 共通UID
- runAsNonRoot: true
- readOnlyRootFileSystem: true
- allowPrivilegeEscalation: false
- setuid（権限昇格）のmechanismから守る．
- Capability
- 従来のnormal/super ユーザ問題への対応
- default CapabilityのDropと特定のCapabilityのadd
- 一部のConfigはPodのレベルでも〇
- Pod Security Policy リソースにより，クラスタ levelでsecurityを指定
- Podのサービス Accountの指定
- defaultは,Namespaceのdefaultのサービス Accountが持つpermissionで実行
- principle of least privilege
- (4) Volume
- 同じPodの別のコンテナとのデータ共有 & restart後もデータを永続保持
- emptyDir
- download fileや生成データのcaching
- データ処理ジョブ用のtmpworkspace
- Pod内コンテナのファイル共有
- コンテナへのマウント方法
- PodのVolumes field
- コンテナのvolumeMounts field
- lockはない
- 永続Volume
- DBはほかのクラウドで〇．Kubernetesは×．
- ↑ stateless Kubernetesのため．
- DBはほかのクラウドで〇．Kubernetesは×．
- (5) restart policy
- restartPolicy: Always(default)/ OnFailure/ Never
- → Job リソース
- (6) Image Pull Secret
- registryに認証情報を提供
まとめ
- コンテナの概要
- Pod内でのコンテナの連携
- Kubernetesでのコンテナの実行のコントロール
Ch09 Pod 管理
目的
- Podのfeatureを見る
概要
- (1) Label
- definition: PodなどのObjectにつくkey-value pair
- core システムのsemanticsを直に構成しない．Object識別属性を指定するためのLabel
- e.g. Podが属するアプリケーションをlabeling → documentation
- selectorと組み合わせて価値が生じる
- selector: Label(or Labelのset)との一致条件を記述
- → リソースのグループをLabelでspecify
- 用途
- サービスとPodを接続
- kubectl get ~ --selector(-lでもOK) app=demo
- --show-labelsでLabelを確認
- selector: Label(or Labelのset)との一致条件を記述
- サービスは等価selectorのみ
- Labelの使い方
- staging/real
- カナリアデプロイ track: stable/canary
- Label: リソースを識別 ←→ Annotation: 外部toolやservice
- どちらもk-v pair
- definition: PodなどのObjectにつくkey-value pair
- (2) Node Affinity
- schedulingの選好性の表現
- hard: required ...
- soft: preferred ...
- schedule時のみ
- Hard Affinity
- Podを実行させたいノードの種類を述べる． @nodeSelectorTerms
- Soft Affinity
- weightの指定
- schedulingの選好性の表現
- (3) PodのAffinityとAnti-Affinity
- ノード内のPodの状態をAffinityに反映する
- Podの同居: hard/soft Pod Affinity
- Podの分離: podAntiAffinity
- soft Anti-Affinity
- Pod Affinityでしか解決できない問題にのみ使用
- (4) Taint(汚染)とToleration
- ノードの属性に基づき，ノードがPodを避ける
- kubectl taint ←→ kubectl taint ~-(-: minusでdelete)
- TolerationでTaintにも許容
- e.g. networkが×のときのunreachable
- (5) Pod Controller
- 手動workのautomate
- 主要はデプロイ → ReplicaSetを管理
- デプロイ以外
- DaemonSet: クラスタ内の個々のノードで，Podのcopyを1つだけ実行
- e.g. logging
- StatefulSet: Podを特定の順序で起動・終了
- 番号でPodを識別 to Redis, MongoDB, Cassandra
- Headless サービスでaddress指定
- DaemonSet: クラスタ内の個々のノードで，Podのcopyを1つだけ実行
- Job: Podを指定した回数だけ実行する
- ←→ デプロイ Pod数を指定しcontinuousに実行
- completions
- parallelism
- Cron Job
- Jobのschedule
- Horizontal Pod Autoscaler(HPA)
- needsに応じてKubernetesがreplica数をautoscale
- Vertical: replica自体を大/小化
- CPU使用率などのメトリクス{での決定, の指定}
- システム/service(← ユーザのdefinition) メトリクス
- needsに応じてKubernetesがreplica数をautoscale
- Pod Preset
- admission controllerの一部
- admission controller: objectへの変更を監視．変更の直前にaction
- Pod Presetのconfigは，個々のPodのconfigとmergeされる
- admission controllerの一部
- OperatorとCustom リソース Definition
- ステートフル setを超えたcomplicateな管理が必要なアプリケーションのため．
- (6) Ingress リソース
- (7) Istio
- サービス mesh: 複数アプリケーションsやサービスの相互通信のある環境の運用のための技術
- (8) Envoy
- 高度なload balancer
作用
- Kubernetesの全てはPodの実行にかかわる
Ch10 Config, Secret データ
目的
- Kubernetesのlogicとconfigの分離
- Podのspecでdefineする環境変数で値をアプリケーションに引き渡す
- or ConfigMapとSecret ObjectでConfigをKubernetesに直に保存
概要
- (1) ConfigMap
- KubernetesにConfig データを保存するためのmain Object
- kubectl create configmap demo-config --namespace=demo --from-file=config.yaml で作成
- kubectl getでManifestを出力
- ConfigMapで環境変数を設定
- ConfigMapから環境全体を設定
- encFromでConfigMapから全keyを取り込む
- ←→ envがprior
- encFromでConfigMapから全keyを取り込む
- command argumentで環境変数を使う
- $(VARIABLE)は環境変数のVARIABLEの値で置き換える
- → コンテナのentry pointにcommand line argumentとして与えられる
- $(VARIABLE)は環境変数のVARIABLEの値で置き換える
ConfigMapからConfig fileを作る
'''
データ: config: | greeting: Buongiorno'''
- |は生データのblockを表す
'''
volumes: - name: configMap: name: items: - key: config path: demo.yaml'''
Configの変更を伴うPodの更新 @Helm
- Annotationを設定 @デプロイのyaml
- (2) KubernetesのSecret
- (3) Secret Data Management戦略
- 問題
- secret データの可用性のための保存場所
- running アプリケーションがsecret データを使う
- secret データの変更へのrunning アプリケーションの対応
- version 管理でのsecret データのencrypt
- デプロイ時にdecrypt
- secret データのrotationがdifficult
- 容易さ〇，柔軟さ〇
- secret データのremote 保存
- 一元補完
- 手間アリ
- 変更の管理のために監査ログが必要
- workflow必要
- 専用のsecret データ 管理 tool
- 大規模組織のみ
- infrastructureがcomplicateになる．コスト大
- 推奨
- SOPSなどの軽量encrypt toolのuse
- 問題
- (4) SOPSでのsecret データのencrypt
作用
- 必要なconfigやデータをアプリケーションと結びつける方法の理解
Ch11 Security and Backup
目的
- Kubernetesにおけるsecurityとaccess controllの仕組みの検討
- 脆弱性をscanするための代表的toolやservice
- Kubernetesのデータとstateのbackup と復元方法
概要
- (1) access controllとpermission
- クラスタ別のaccess controll
- クラスタ運用者/ アプリケーション developerの2group化
- 本番/ staging
- RBAC(Role-Based Access Control) @Kubernetes
- 有効化
- 確認: kubectl describe pod ...
- 有効化
- Role
- ユーザが持つpermissionの特定のsetをroleが統制
- namespaceやクラスタを対象に
- RoleBinding ObjectでユーザとRoleを紐づけ
- 加法的Permission
- 必要なrole: defined roleのクラスタ-admin, edit, viewでおおよその要件は〇
- クラスタ-admin ≒ root
- not クラスタ 運用者やinternetにopenなservice accountには×
- アプリケーション専用のservice accountに対してRoleBinding Objectでroleを紐づける
- CD toolにのみアプリケーションのデプロイを許可
- "edit" role
- RBACの問題の対処方法
- API serverのログでRBAC DENYを探す
- クラスタ別のaccess controll
- (2) Security Scan
- (3) Backup
- (4) クラスタのstatusの監視
- kubectl
- クラウド providerのconsole
- Kubernetes Dashboard
- securityが重要
- never public internet
- minimumの権限．kubectl proxy経由のaccess
- 不要なら使わない
- Weave Scope: クラスタの監視と視覚化
- kube-ops-view: クラスタ内の視覚化
- ノード-問題-detector: Kubernetesのaddon ノードの問題の検出
作用
- 知識・思考・注意を要するcontinuous プロセス: security
Ch12 Kubernetes アプリケーションのデプロイ
目的
- Manifest fileからアプリケーションを実行
- アプリケーション用のHelm Chartのbuild
概要
- (1) HelmでのManifestのbuild
- fileの保守 + 配布の問題を解決
- 設定値や変数を生のmanifest fileから分離
- ほかのアプリケーションやserviceへの依存関係も公開できる
- Chartの内部校正
- Helm template
- 依存関係の指定 → helm 依存関係 update
- requirements.yaml
- fileの保守 + 配布の問題を解決
- (2) Helm Chartのデプロイ
- 変数の設定
- 追加の値file. releaseにおける値の指定: helm install ~ --values...
- 値の確認: helm inspect values
- Helmでのアプリケーションの更新．何度でも〇
- helm upgrade \<既存のデプロイ>
- 追加の値file. releaseにおける値の指定: helm install ~ --values...
- 指定のversionへのrollback: helm rollback \<デプロイ name> 1
- rollforwardもrollbackで〇
- helm-monitorによるauto rollback
- Helm Chart Repositoryの作成
- 普通はアプリケーション独自のrepositoryに保存のため不要
- Secret by SOPS in Helm Chart
- secret データを値fileにいれ，SOPSでencrypt
- command, 適用手順
- 変数の設定
- (3) Helm fileによる複数 Chartの管理
- (4) 高度なManifest 管理 tool
- ksonnet: 計算やlogicが必要な大規模でcomplicateなデプロイに〇
- → projectが中止
- Jsonnet: JSONの拡張．KubernetesはJSONも〇
- prototypeの導入: よく使われるManifest pattern
- Kapitan
- 設定値の階層DB: inventory
- → 環境やアプリケーションに合わせて異なる値でmanifest patternを再利用
- 設定値の階層DB: inventory
- kustomize
- plainなYAML
- overlayでパッチとして適用
- kustomize build ~ | kubectl apply -f ~
- kompose
- docker-compose.yml: 連携して機能する一連のコンテナを定義, and デプロイ + コンテナの通信方法を定義
- → Kubernetes Manifestに変換するtool
- Ansible
- 混合infrastructureの場合に強力
- Kubernetes クラスタのinstallと設定
- Kubernetes moduleでデプロイやサービスなどのKubernetes リソースを直に管理
- kubeval
- Manifestの検証 to schema by version
- CD パイプラインへの追加が〇
- Conftestも〇
- ksonnet: 計算やlogicが必要な大規模でcomplicateなデプロイに〇
作用
- Kubernetesでのデプロイの簡単化
Ch13 Development workflow
目的
- localのdevelopmentからKubernetes クラスタへの更新のデプロイまでのアプリケーションのlifecycleを扱う
概要
- (1) development tool
- Skaffold: development workflowのspeed up
- skaffold.yamlにworkflowを定義
- → skaffold command line toolの実行でパイプライン start
- Draft
- Skaffoldと同様， by Azure team
- Draft Pack: アプリケーションが使用する言語に対応したDockerfileとHelm Chart
- draft init && draft createで言語を特定
- リソースの適用: draft up
- Telepresence: local machineをremote クラスタに参加させられる
- Knative: 開発中． コンテナ化されたアプリケーションやserverless styleの機能を含めたあらゆるworkloadをKubernetesにデプロイ
- KubernetesとIstioの両方と統合
- build プロセスのsetup, デプロイ のautomate, Eventing
- Skaffold: development workflowのspeed up
- (2) デプロイ戦略
- zero downtime デプロイ → ユーザのリクエストに対応するアプリケーションでは必要
- Rolling Update( 0 downtime ) ←→ Recreate (high speed)
- デプロイ Manifestで定義
- default: RollingUpdate
- minReadySecondsでroll outをPodの安定まで待機． @RollingUpdate
- MaxSurgeとmaxUnavailable: 基本は変える必要なし
- blue green デプロイ
- サービスからtrafficを受信するPodを決定するため，Labelを使う
- → サービスのselectorのdeployment fieldに設定
- blue, green, ... → rainbow デプロイ
- canaria デプロイ → Istioを使うと高度なデプロイが〇
- (3) Helmでの移行
- DBがかかわるときに必要な「移行」
- Job リソースで実現
- Helmのhookで可能
- Job リソースで実現
- Helmのhook: デプロイ中の処理準をcontroll
- JobのAnnotationで指定
- 失敗にも対応〇
- pre-upgrade以外のhook
- hookのchain化: 複数 hooks をchain化 by order
- helm.sh/hook-weight propertyを使う
- DBがかかわるときに必要な「移行」
作用
- Kubernetes アプリケーションの開発の高速化． by tools
- 変更の本番環境へのrooloutが容易
Ch14 KubernetesでのCD
目的
- CDとCDのKubernetes based クラウドネイティブ 環境での実現
- Kubernetesと連携して動くCD パイプライン
- コンテナ化されたアプリケーションのパイプラインの典型
- codeの変更をgit repositoryにpush
- build システムがbuild & test
- test ok → コンテナ イメージがコンテナ Registryに対してpublish
- new builded コンテナがautomatically デプロイ to staging 環境
- automatic acceptance test in staging 環境
- tested コンテナ イメージ tobe デプロイ to production 環境
- デプロイの対象の成果物は〇コンテナ， ×Source Code
対応
- (1) CD tool
- (2) CDのComponent
- 既存のCDにコンテナ用Componentの追加のe.g.
- Docker Hub
- Gitkube: self hosting. simple + 可搬性〇．setupも間t何
- Flux: with GitOps extended
- Keel ≒ Flux
- 既存のCDにコンテナ用Componentの追加のe.g.
- (3) CD Pipeline のe.g. by Cloud Build
- Google CloudとGKEのセットアップ
- test run
- アプリケーション コンテナのbuild → アプリケーション コンテナの作成
- Kubernetes Manifestの検証
- イメージのPublish
- Git SHA tag @成果物 → Codeのsnapshotになる
- triggerの作成: 監視target Git Repository, active化の条件, パイプライン fileの指定
- triggerのテスト
- CD パイプラインからのデプロイ
- Kubernetes クラスタへの認証情報の獲得
- ユーザ definitionの置換
- 環境 tagの追加
- クラスタへのデプロイ
- Kubernetes クラスタへの認証情報の獲得
- デプロイ triggerの作成
- tagのpushでtrigger
- 代入変数
- Build PipelineのOptimize
- コンテナ based CD Pipeline toolは，各stepのコンテナをminimize
- multi stage buildでオリジナル custom イメージをbuild
- コンテナ based CD Pipeline toolは，各stepのコンテナをminimize
作用
- アプリケーションのためにCD Pipelineをsetup → 一貫した方法と高い信頼性でソフトウェアを迅速にデプロイ
Ch15 オブザーバビリティと監視
目的
- オブザーバビリティと監視の関係
- Kubernetesでの監視，logging, メトリクス tracingの扱い
概要
- (1) オブザーバビリティ
- 監視を超えた概念
- 監視
- automatic 監視 @DevOps
- blackbox監視
- up/down test
- logging: 中央DBに集約 → 問題のtrouble shoot
- limit: developerのjudgeで作成．query difficult, signal/noise比が△
- scale difficult
- logを超えた方法が必要 → Metrics
- メトリクスの導入
- @アプリケーション's メトリクス
- @Infrastructure's メトリクス
- プロセス/コンテナのCPU使用率
- ノードやServerのdisc I/O activity
- machine, クラスタ, load balancerのI/O network traffic
- メトリクス: 「なぜか」の解決に有用
- 予測にも使える
- アプリケーションを内部から監視
- 実際の動作に基づいてシステムの隠れた側面に関する重要 情報を外に伝えられる
- → 〇内からの監視/ ×reverse engineering
- tracing @分散 システム
- メトリクスやtracingなど全体をカバーした用語としてのオブザーバビリティ: システムがなぜ正しく機能しないのかの理解
- ←→ 監視: システムが正しく機能しているかどうか
- データについてのオブザーバビリティも重要
- 不透明なソフトウェアを測定
- Codeのdevelopmentとproduction 環境での大規模実行との間のloopを縮める重要 tool culture
- (2) オブザーバビリティ Pipeline
- bufferによる統合 with standard メトリクス style by structured データ
詳細
- Kubernetesでの監視
- 外部からのblackbox check
- 監視はユーザの挙動を模倣
- 外部からサービスの可用性を監視 vs 機能停止: Monitoring as a サービス
- 既存サービスを使用する（安価 or freeのため）
- 内部health check
- ユーザ's happinessが観点となる
- @コンテナ
- × Liveness check
- 〇 Readiness check to 依存関係 failures
- circuit breaker pattern
- elegant 劣化とする
- 外部からのblackbox check
作用
- クラウドネイティブ環境で監視が目指すべき方向性
- オブザーバビリティの価値 with メトリクス
Ch16 KubernetesにおけるMetrics
目的
- Metricsの扱い方
- Metricsとは
- 特定の対象を測定した数値
- → 特定の瞬間における状況のsnapshot + 変化を示す
- 時系列データ by sampling
- メトリクス値: Counter/Gauge
- Counter: increment only or reset to 0.
- 量の表現
- Gauge: 増減〇. memory使用率など
- 比率の表現
- Counter: increment only or reset to 0.
- 異常やfailureの通知 + 機能状況の表示
- → 「なぜか」の解決
- 特定の対象を測定した数値
概要
- (1) 優れたメトリクスのchoice
- メトリクスの一部へのfocus
- 要件ごとのオブザーバビリティのためのメトリクス pattern
- service: RED pattern
- リソース: USE pattern → 性能問題の分析とボトルネックの発見のためのbottom up型の方法 ←→ service
- :システムの健全性のcheck, 高速で可視性高い
- Utilization: 使用率
- Saturation: 飽和度
- Error
- 対象は〇リソース/ ×Service
- → システム 性能のbottleneckの発見
- e.g. CPU, disc, networkのIFやLink
- → システム 性能のbottleneckの発見
- ビジネス メトリクス
- 加入者についてのデータの把握
- funnel analysis
- 解約率
- 収益/顧客
- help, support pageの有効性
- System Status pageへのtraffic量
- funnel analysis
- 共通のdatalakeを使用 in two or more groups
- 加入者についてのデータの把握
- Kubernetesのメトリクス
- クラスタ healthのメトリクス
- ノード数
- ノードのhealth status
- Pod数/ノード or Pod数 in all
- リソース使用率, 割り当て by ノード or 全体
- クラスタ healthのメトリクス
- デプロイのメトリクス
- デプロイの数
- デプロイごとのreplicaの設定数
- デプロイごとの利用不可のreplicaの数
- コンテナに関するメトリクス
- コンテナ/Podの数 by ノード or 全体
- リソース使用率 to リソース要求/リソース制限
- コンテナのLiveness/Readiness
- コンテナ/Podのrestart 数
- 各コンテナのnetwork I/O traffic and error
- アプリケーションのメトリクス
- アプリケーションの機能による
- 性能や可用性の問題のため
- アプリケーションの実行内容，頻度，処理時間
- とりあえず不明なら記録する
- SLOやSLAに対するアプリケーションの性能も知る
- runtimeのメトリクス
- プロセスのrun statusを知る
- 6こ
- 性能の劣化やcrashについての診断に〇
- プロセスのrun statusを知る
- (2) メトリクスの分析
- (4) メトリクスのdashboardによるグラフ化
- (5) メトリクスに基づくアラート
- アラートの問題
- 分散 システムは完全upにはならない
- S/N比を高める必要
- アラートは，直ちに人間が対処すべきもの(という単純な事実)のみ表すべき
- いずれ対処 → mail, chatでのアラートでよい
- OnCallの負担の軽減の重要性
- アラートは緊急かつ重要で対処可能なもののみ
- → 一握りのメトリクスに限定
- → そうでないものは非同期通知
- 要因についてのメトリクス
- アラートの問題
- (6) メトリクス 管理のtool, サービス
- OSSが優秀
- Prometheus: defact standard with Kubernetes
- scraping(収集) プロセスでautomaticにメトリクスを収集
- Helmでcommand 1つでKubernetes クラスタにinstallできる
- simpleな構成・仕組み
- pull type の監視
- Grafanaなどで，Prometheusで収集・保存した情報を活用
- → 時系列データのグラフ化
- Alertmanager
- 重複排除 → アラートのグループ化 → 通知serviceにルーティング
- Open メトリクスのbaseとなっている
- その他のtools
作用
- proper データの収集 → proper方法で処理 → properな問題の解決に活 → proper方法でvisualize → properな事項をproperな対象者にアラート
