『Kubernetesで実践するクラウドネイティブDevOps』学習メモ

Ch01 Cloud Revolution

目的

  • 3つの革命
    • cloudの創造
    • DevOps
    • Container
  • → Cloud Native with OS:Kubernetes
  • revolutionのhistory, importanceを見て,software deliveryへの作用を考える
    • 想定される変化
  • Cloud Native DevOpsがtheme

概要

  • (1) cloud
    • 処理能力を買う
    • SaaS
    • Iaas
      • Undifferentiated Heavy Lifting(UHL)
  • (2) DevOps
    • developmentとoperationsの連携
      • 信頼性と正確性の責任共有
      • 拡張性Up
    • 技術ではなく組織力,人間の問題
    • merit in business
    • Infrastructure as Code
      • cloudをautomateするsoftwareのdeveloperが運用エンジニア
    • collaboration型でコード中心 → container
    • development, operationsの統一
  • (3) container
    • dependency, config
    • history, background
      • Puppet, AnsibleなどのConfig Management System
      • omnibus package
      • VM Image
        • problem多い(コスト,不安定)
    • 特性: 可搬容量,コストdown, 規模の経済,扱いやすさ
    • image fileをcontainer runtimeで実行
    • 仮想化による実行効率downの解決 with real CPU
    • file systemのlayerをaddress指定
      • → container間でlayerの共有や再利用〇
    • containerは再利用の単位
      • scalingの単位,resource配分の単位でもある
    • containerが依存するのは唯一OSのkernelのみ
      • distributed systemの設計パターンを開発
      • container orchestrator
        • clusterとして一体化
        • orchestration + scheduling
        • cluster management
    • kubernetes
      • history @ Borg
        • containerをserverのpoolで実行するための割り当てとschedulingを行う集中管理system
    • values
      • kubernetesによる従来のsystem management taskのautomate
      • deployの容易さ
        • zero down time deploy with Rolling Update
        • canaria deploy, bluegreen deploy in Continuous Deploy
        • auto scale
        • 冗長性とfail overでの信頼性と耐障害性up
        • cost down by 能力の浪費cut
        • cloud providerと疎である by kubernetesの抽象化
        • containerはsoftwareを定義するための可搬性の方法 & kubernetes resourceはsoftwareの実行方法の可搬性のための方法
    • kubernetesの制約
      • DBなどのstatefulなworkloadへのcost 大
      • → 代わりにmanaged serviceを使用
      • Faas, (server served platform). e.g. AWS Lambda
      • functionとcontainerのhybrid: Funtainer
        • → Knative
  • (4) cloud native
    • 一般的用法: cloud, container, orchestrationを活用し,多くの場合OSSをbaseとする,最先端applicationやserviceを簡潔に表現する手段.
      • 自動化されたInfrastructure as Code
    • 特性
      • automate可能
      • Ubiquitous and flexible
      • resilient(弾力的) and scalable
      • dynamic
      • Obserbable
      • distribution: 分散化,非集中化
        • codeを単一のentity(monolithus)としてdeploy
        • or multi distributed micro servicesで構成
        • monolithusの方が理解しやすく,相互作用を追跡できる
          • but, monolithusは拡張difficult

作用

  • 運用の観点
    • Developer Productivity Engineering(Developer生産性工学), DPE team
    • Site Reliability Engineering(SRE)
    • kubernetesのimportance pointsのまとめ

Ch02 kubernetes first step

概要

  • Docker
    • Dockerはpluralで異なる but 関連する要素から成る
    • container image format
    • container run time library
      • containerのlifecycleのmanagement
    • command line tool
    • container management用API
    • container image: ZIP fileのようなもの
      • 実行のためには,ID or URLを指定するだけ

詳細

  • (1) Container build

    • docker image build with Dockerfile
      • Dockerfile specifies all what image has to have
      • 既存のimage(: base image)にもとづいて新しいimageをbuild
      • multi stage build
        • scratch imageにbuilded binaryをcopy → 軽量化, attack surface(攻撃対象領域)の縮小
      • -tによるtagづけ
      • portの転送

          '''
           -p HOST_PORT:CONTAINER_PORT 
          '''
        
  • (2) Container Registry

    • Docker IDをgetし,Docker Hubにoriginal imageをpush
    • imageの命名とpush
      • → どこからでもcontainer imageを実行可能
  • (3) kubernetes
    • Enable Kubernetes @Docker Desktop
    • demo applicationの実行
      • deploymentのcreate
      • port forward
  • (4) Minikube

まとめ

  • Containerをbuild and runの実践

Ch03 kubernetes environmentの選択

目的

  • clusterのbasical structureの理解
  • kubernetesの実行方法を決定するための情報
  • managed serviceの長短

概要

  • clusterのarchitecture
    • kubernetesがmulti serverを接続して1つのclusterとする
    • controll plain
      • このcomponentを実行するメンバ(ノード): master node
      • kube-apiserver
      • etcd: DB
      • kube-scheduler
      • kube-controller-manager
      • cloud-controller-manager
    • nodeのcomponent @Worker node
      • kubelet
      • kube-proxy
      • container runtime
    • 高可用性
      • network partitionも処理〇
      • controll platformの高可用性の重要性
        • quorumを維持
          • e.g. 本番clusterは3つが最小
    • 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 cluster
      • auto scale
    • EKS
      • 後発&割高
    • AKS
    • OpenShift: PaaS
    • IBM Cloud Kubernetes Service
    • HKs
  • (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: 変更をnode 設定にrolloutする処理の迅速性と安全性up
    • RKE: simple & high-speed
    • Puppet kubernetes module
    • Kubeformation: 既存のautomate toolのwrapper
  • (5) 原則
    • running softwareを減らす
      • standard technologyのuse
      • cost 大のタスクはoutsource
      • 長寿の競争優位
    • → managed kubernetesの推奨
    • cloud native: 差別化につながらない要素をoutsourceしbusinessを加速
    • self-hostingならkops, Kubespray
    • 限られた予算 e.g. Raspberry Pi
  • (6) clusterless container service

まとめ

  • kubernetes clusterをservice providerに任せ,確実性と経済性を得る

Ch04 kubernetes objectの基本操作

目的

  • kubernetesの基本object: Pod, Deployment, Service + Helm tool

概要

  • (1) Deployment
    • Superviserの機能 @kubernetes
    • 個々のprogramに対応
      • Deployment Objectを作成
        • Deployment controllerによる制御
    • Default: containerのrestart
    • Deployment information get command
  • (2) Pod
    • 1つ以上のcontainerのgroup ← クジラの群れ
    • Podの仕様(spec: specification)のcontainers list
    • kubectl run: Deploymentを作成 → DeploymentがPodを起動
    • Deployment: 「あるcontainerを持つPodを1つ実行し続ける必要がある」といった,望ましい状態の宣言
  • (3) ReplicaSet
    • Deployment-ReplicaSet-Pod
    • ReplicaSet controllerが必要な数(同一)のPod,ReplicaSetのgroupを管理
    • → DeploymentがReplicaSetを管理: userのReplicaSetのupdateをcontroll

詳細

  • (1) Keep desirable state
    • 調整loop
      • Deploymentのshutdown
  • (2) kubernetes scheduler
    • Deploymentがkubernetes DBにPod resourceを作成 & Pod into cueue
      • → schedulerがPodを取り出してrunnabeなnodeを見つける
      • ⇔ Podをnodeにscheduling
      • → kubeletがPodが含むcontainerを起動
  • (3) YAML形式のresource manifest
    • kubernetesは本質的に宣言的
      • → continuous reconcliation(調整; cal-, -cli-: 呼び集める)
    • → specを変更すればkubernetesが処理してくれる.
    • DeploymentやPodなどのkubernetesのresourceはすべて内部のDBのrecordで表現
      • 「kubectl run」でnew recordをinsert or 「resourceのmanifestを読み取るよう指示」
    • container imageの名前とPortが重要
      • @DeploymentのYAML Manifest
      • ↑→ kubectl runで指定していた
    • kubectl applyでmanifestをclusterに送信
    • Service resource
      • 単一の変化しないIP address or DNSnameを付与
        • → 対応するPodへ自動routing
        • → Podにnetwork経由でconnect
      • Web proxyやload balancerのようなもの
        • backendのPodのgroupにrequestを転送
    • ServiceのYAML Manifest
      • multi Pod → load balance
    • 後始末 kubectl delete -f kubernetes/.
      • Manifestのdirectoryをdelete
    • kubectlでのclusterへのquery
      • kubectl get
      • kubectl describe pod/dem-dev-6c...
    • YAML Manifestでの宣言的deployにおける繰り返しの解消 → Helm
  • (4) Helm: kubernetes package manager
    • command line toolでDeployment resourceとServiceをHelmが作成.
      • applicationをinstall and configure
      • chart: real container imageを含まないyaml manifestのwrapper.同じcluster内に何度もinstall可能
        • applicationをkubernetesで実行するために必要なresourceの定義がすべて格納されるHelm package
      • repository: chartの収集と共有
      • release: kubernetes clusterで実行されるchartの特定のinstance
      • helm install -name
      • helm list, helm status

作用

  • 何ができるかを理解
    • ↑ PodやDeploymentのメカニズム

Ch05 Resource management

目的

  • clusterの最大活用
    • resourceの使用状況の管理と最適化など

概要

  • resourceの理解
    • kubernetes schedulerの観点
      • Podが求めるresourceの量を把握
    • resourceの単位: CPU, milliCPU, MiB@memory
    • resource要求: min
    • resource制限: max
      • over commit〇: nodeのresource総量を超えた制限可能
    • containerのminimize

詳細

  • (1) container lifecycle management
    • Liveness probe by HTTP
    • Probeの遅延と頻度
      • death loopの回避
      • initialDelaySeconds, periodSeconds
    • ほかのtypeのProbe
    • Readiness Probe: 「一時的にrequest処理不可能」を知らせる. → 常に「200 OK」を返す必要
      • zero downtime upgradeにeffective
    • file based Readiness Probe
    • minReadySeconds
    • Pod Disruption Budget: 失ってもよいPodの数
      • minAvailable, maxUnavailable
  • (2) Namespace
    • cluster横断でresourceの使用状況を管理
    • clusterをpartition化
      • 別のnamespaceからは見えない
    • nest不可
    • kubectl get pods --namespace production
    • default namespaceは使わない
    • Service間の通信
      • Service -DNSname e.g. SERVICE.NAMESPACE.svc.cluster.local
    • namespaceでのresourceのcontroll → ResourceQuota
      • kubectl get resourcequotas -n demo
    • LimitRangeでnamespaceないのdefaultを指定
      • ただし,基本はcontainerに設定する → containerを見ればわかるように
  • (3) cluster cost optimize
    • Deploymentのoptimize
      • serviceが求める処理能力と可用性のbusiness要件
      • その要件より少なく達成できるか
    • Podのoptimize
      • normal 運用のmax + α → resourceのPackman状態の回避
    • Vertical Pod Autoscalar
    • Nodeのoptimize
      • 観察
      • 典型的なPodをat least 5個実行数rのに十分なサイズ
      • stranded resource(残されたresource)の割合をunder 10%
      • 10個いじょうなら5%
    • Storageのoptimize
      • I/O operation 毎秒(IOPS)で観察
      • 未使用resourceのclean up
        • kubeletのgarbage collection設定を調整
      • 所有者metadata Annotationを使用し,Annotationのないresourceを強制終了候補にする
        • ↑ すべてのresourceに所有者Annotationを設定
      • 使用率が低いresourceの発見
        • 受信requestの数をPodがメトリクスとして公開
        • Web コンソールで各PodのCPUとメモリの使用率の数値をチェック
      • finished jobのclean up
    • 余剰capacityのcheck
    • reserved instanceのuseでのcost down
    • preemptive (spot) instance
      • preemptive nodeはcluster全体の2/3以下にする
      • node affinityでpreemptive nodeへのscheduling制御
    • kubernetes scheduler: workloadを多くのnodeに均等にassign & replicaを異なるnodeにおいて高可用性
      • schedulerはnode間でPodを移動しない.
        • → Deschedulerというtoolでのmove

Ch06 clusterの運用

概要

  • (1) clusterのsizingとscaling
    • clusterのcostにはnodeの数とサイズが作用する
    • capacity plan
      • min cluster
        • 耐障害性, min: 3 master node
        • 高可用性, min: 2 worker node to fault tolerant
      • max cluster
      • 連合cluster
      • 基本は本番とステージングに各1つのcluster
        • clusterのpartitionならnamespace
    • nodeとinstance

      • node size ← providerが提供するcost performanceが良いものを選択
      • cloud instanceのtype
        • 1つのvCPU + 3~4GiBのmemoryがmin
      • special typeのnode e.g. gpu, windows
      • bare metal server
    • clusterのscaling

      • instance group, node pool
      • scale down
      • automatic scale → 基本は不要
  • (2) 適合性チェック
    • test suite がkubernetesにある
    • CNCF認定: Certified Kubernetes, CKA, KCSP
    • Sonobuoyでの独自clusterのtest or managed service
      • Sonobuoy Scanner
  • (3) 検証と監査
    • tool
      • (kubernete Guard: kubernetes clusterのcommon problem check)
      • Copper / instrumenta / Conftest
      • kube-bench: 不要なことも多い
      • kubernetesの監査logging
  • (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
    • resource 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・・・
  • (2) resourceを使った作業
    • 命令的(←→宣言的)なkubectl command (imperative(←→declarative))
      • kubectl createでresourceをexplicitlyに作成
      • kubectl deleteでresourceを削除
      • kubectl edit
    • 本番clusterにはimperativeは×
      • 代わりにkubectl apply
    • kubectlでのmanifestの作成
    • resourceの差分チェック: kubectl diff -f dep.yaml
      • kubectl applyの前に行う
  • (3) Containerを使う作業
    • log: containerがstandard output or standard error outputのstreamに書くものすべて
    • logの閲覧: kubectl logs -n kube-system --tail=20 --follow(-f) etcd-docker・・・
      • → supervise continuous output
      • --tail/--since/--timestamps
    • containerへのattach
    • Kubesprayでのkubernetes resourceの監視
    • Container Portの転送: kubectl port-forward
    • Containerでのcommand execution: kubectl exec
    • debugのためのcontainer実行
      • kubectl run NAME --image=IMAGE --rm(→del after completed) --it(i: 対話型, t: terminal) --restart=Never --command --・・・
    • BusyBox(BB) commandの仕様
      • 対話型のshell in cluster + shell alias → bb
    • BBのcontainerへの追加
      • BBはたった1MiB
      • DockerfileでCOPY --from 命令
        • → kubectl exec -it POD_NAME /bin/busybox sh
    • containerへのprogramのinstall
    • kubesquashでのlive debug(本格的debugger)
      • debuggerをcontainerにアタッチ: kubesquash
      • with goのdebugger: dlv
  • (4) ContextとNamespace
    • Context: cluster, user, Namespaceの組み合わせ
      • → bookmarkになる
    • kubectl: 今のContext
      • kubectl config get-context
    • kubectxとbubensでContext切り替え高速化
    • kube-ps1で現在のContextをpromptに追加
      • → [( )]
  • (5) kubernetesのshellとtool
    • kube-shell: 補完のpopup
    • Click: 対話型kubectl
    • kubed-sh: cluster自体の上でprogramを実行
    • Stern: log
  • (6) original kubernetes toolの構築
    • client-goでkubectlができるすべてをrealize

作用

  • kubectlで必要なことは何でもできる

Ch08 Containerの実行

目的

  • ~Ch07: 運用
  • Ch08: 最も基礎的なObject in kubernetes: Container

概要

  • (1) ContainerとPod
    • Pod: kubernetesでの{minimum deploy, schedule}単位
      • Pod Objectが{単一/複数のgroup} Containerを表す
      • kubernetesすべての実行はPodを使用する
      • 同じ実行環境上のapplication container + storage volumeの集まり
        • 1つのPod内のContainerはすべて同じマシン上に配置
    • Container: 1つのsoftware, dependency, config, dataなど,実行に関するものすべて
      • 実行の担保はprocess
        • process: 実行するapplicationのbinary codeとmemory statusを表現し,同じglobalなNamespaceに存在
          • → process間のやり取り〇.同じresourceのpoolを共有
      • Container: original Namespace内にある分離されたprocess(のgroup)を表現する
      • Containerの内外ではprocessは隠れる
    • Containerの構成要素
      • 軽量VM
      • 1つのことのみ実行 e.g. 単純な自己完結型service
      • entry point: 起動時に実行されるコマンド
    • Podの構成要素
      • Pod: 相互に通信してdataを共有する必要がある
        • Containerのgroupを表現
        • ともにschedule. 起動終了も同時.同じ物理マシン上で実行
          • ⇔ 常に同じnode上で実行
        • 異なるマシンで動作しないcontainerをPodでgroup化する
  • (2) ContainerのManifest
    • 複数のContainersのtemplate spec
      • name, image
    • image識別子
      • registry hostname, repository Namespace, image repository, tagの4つで構成
      • tagの例
    • latest tag
      • default: latest e.g. alpine:latest
      • 本番環境ではlatestは×
    • Containerのdigestで決定的deploy
      • ←→ tagでの非決定的deploy
    • base imageのtag
      • 特定のtag/ digestのuse
    • Port: kubernetes上には意味なし.しかし,Manifestには含める
    • resource要求制限
    • imageのpullについてのpolicy: imagePullPolicy
      • 基本はIfNotPresent
    • 環境変数の設定
  • (3) ContainerのSecurity
    • principle of least privilege
      • bug riskのminimize
    • 一般userの割り当て: runAsUser
      • UID 1000: first not root user
      • security maximize: ContainerごとのUID
      • dataを共有するためのアクセス: 共通UID
    • runAsNonRoot: true
    • readOnlyRootFileSystem: true
    • allowPrivilegeEscalation: false
      • setuid(権限昇格)のmechanismから守る.
    • Capability
      • 従来のnormal/super user問題への対応
      • default CapabilityのDropと特定のCapabilityのadd
    • 一部のConfigはPodのレベルでも〇
    • Pod Security Policy resourceにより,cluster levelでsecurityを指定
    • PodのService Accountの指定
      • defaultは,NamespaceのdefaultのService Accountが持つpermissionで実行
  • (4) Volume
    • 同じPodの別のContainerとのdata共有 & restart後もdataを永続保持
    • emptyDir
      • download fileや生成dataのcaching
      • data処理ジョブ用のtmpworkspace
      • Pod内Containerのファイル共有
      • Containerへのマウント方法
        • PodのVolumes field
        • ContainerのvolumeMounts field
      • lockはない
    • 永続Volume
  • (5) restart policy
    • restartPolicy: Always(default)/ OnFailure/ Never
    • → Job resource
  • (6) Image Pull Secret
    • registryに認証情報を提供

まとめ

Ch09 Pod management

目的

  • Podのfeatureを見る

概要

  • (1) Label
    • definition: PodなどのObjectにつくkey-value pair
      • core systemのsemanticsを直に構成しない.Object識別属性を指定するためのLabel
      • e.g. Podが属するapplicationをlabeling → documentation
    • selectorと組み合わせて価値が生じる
      • selector: Label(or Labelのset)との一致条件を記述
        • → resourceのgroupをLabelでspecify
      • 用途
        • ServiceとPodを接続
        • kubectl get ~ --selector(-lでもOK) app=demo
          • --show-labelsでLabelを確認
    • Serviceは等価selectorのみ
      • Deployやkubectlなどの高度resourceは,高度なselector
      • e.g.
        • kubectl get pods -l app!=demo
        • kubectl get pods -l "environment in(notin) (staging, production)"
    • Labelの使い方
    • Label: resourceを識別 ←→ Annotation: 外部toolやservice
      • どちらもk-v pair
  • (2) Node Affinity
    • schedulingの選好性の表現
      • hard: required ...
      • soft: preferred ...
      • schedule時のみ
    • Hard Affinity
      • Podを実行させたいnodeの種類を述べる. @nodeSelectorTerms
    • Soft Affinity
      • weightの指定
  • (3) PodのAffinityとAnti-Affinity
    • node内のPodの状態をAffinityに反映する
    • Podの同居: hard/soft Pod Affinity
    • Podの分離: podAntiAffinity
    • soft Anti-Affinity
    • Pod Affinityでしか解決できない問題にのみ使用
  • (4) Taint(汚染)とToleration
    • nodeの属性に基づき,nodeがPodを避ける
    • kubectl taint ←→ kubectl taint ~-(-: minusでdelete)
    • TolerationでTaintにも許容
    • e.g. networkが×のときのunreachable
  • (5) Pod Controller
    • 手動workのautomate
    • 主要はDeploy → ReplicaSetを管理
    • Deploy以外
      • DaemonSet: cluster内の個々のnodeで,Podのcopyを1つだけ実行
        • e.g. logging
      • StatefulSet: Podを特定の順序で起動・終了
        • 番号でPodを識別 to Redis, MongoDB, Cassandra
        • Headless Serviceでaddress指定
    • Job: Podを指定した回数だけ実行する
      • ←→ Deploy Pod数を指定しcontinuousに実行
      • completions
      • parallelism
    • Cron Job
      • Jobのschedule
    • Horizontal Pod Autoscaler(HPA)
      • needsに応じてkubernetesがreplica数をautoscale
        • Vertical: replica自体を大/小化
      • CPU使用率などのmetrics{での決定, の指定}
        • system/service(← userのdefinition) metrics
    • Pod Preset
      • admission controllerの一部
        • admission controller: objectへの変更を監視.変更の直前にaction
      • Pod Presetのconfigは,個々のPodのconfigとmergeされる
    • OperatorとCustom Resource Definition
      • stateful setを超えたcomplicateな管理が必要なapplicationのため.
  • (6) Ingress resource
    • Ingress: Serviceの前のload balancer
    • Serviceはcluster内の内部trafficのrouting
      • ←→ Ingressはclusterやmicroserviceへの入力となる外部trafficのrouting
      • 異なるServiceへの転送: fanout
      • URL, HTTP Host headerでのrouting
    • TLS(SSLと呼ばれていたもの)
      • 証明書の共有を単一のIngress resourceで管理: TLS終端と呼ぶ
      • kubernetesのSecretで証明書を保存
        • 既存証明書も〇
      • Cert-managerでLet's Encrypt証明書を自動取得
        • ↑ kube-legoの後継
    • Ingress Controller
      • Ingress Controllerが認識する特別なAnnotation
  • (7) Istio
    • Service mesh: 複数applicationsやServiceの相互通信のある環境の運用のための技術
  • (8) Envoy
    • 高度なload balancer

作用

  • kubernetesの全てはPodの実行にかかわる

Ch10 Config, Secret data

目的

  • kubernetesのlogicとconfigの分離
    • Podのspecでdefineする環境変数で値をapplicationに引き渡す
    • or ConfigMapとSecret ObjectでConfigをkubernetesに直に保存

概要

  • (1) ConfigMap
    • kubernetesにConfig dataを保存するためのmain Object
    • kubectl create configmap demo-config --namespace=demo --from-file=config.yaml で作成
    • kubectl getでManifestを出力
    • ConfigMapで環境変数を設定
      • applicationの環境変数の読み取り
      • ConfigMapのManifest file
      • Deployの設定
        • image:のtag
        • enc: のfield
          • name-valueのpair
          • valueFromで,literalでなく別のところの値を取得
          • configMapKeyRef
      • Deployは自身のspecが更新されたときのみPodを更新する
    • ConfigMapから環境全体を設定
      • encFromでConfigMapから全keyを取り込む
        • ←→ envがprior
    • command argumentで環境変数を使う
      • $(VARIABLE)は環境変数のVARIABLEの値で置き換える
        • → containerのentry pointにcommand line argumentとして与えられる
    • ConfigMapからConfig fileを作る

      '''

        data:
        config: |
            greeting: Buongiorno
      

      '''

      • |は生dataのblockを表す

      '''

        volumes:
        - name:
          configMap:
            name:
            items:
            - key: config
              path: demo.yaml
      

      '''

    • Configの変更を伴うPodの更新 @Helm

      • Annotationを設定 @Deployのyaml
  • (2) kubernetesのSecret
    • secret dataの保存のためのSecret
    • 環境変数としてSecretを使う
      • secretKeyRef ≒ configMapKeyRef
    • Secretのfileへの書き込み
    • Secretの読み取り
    • RBACによるaccess controll → 11.1.2
    • 保存dataの暗号化
      • kubectl describe pod -n kube-system -l component=kube-apiserver | grep encryption
    • HelmのAnnotationでSecretを保持〇
  • (3) Secret Data Management戦略
    • problem
      • secret dataの可用性のための保存場所
      • running applicationがsecret dataを使う
      • secret dataの変更へのrunning applicationの対応
    • version managementでのsecret dataのencrypt
      • deploy時にdecrypt
      • secret dataのrotationがdifficult
      • 容易さ〇,柔軟さ〇
    • secret dataのremote 保存
      • 一元補完
      • 手間アリ
      • 変更の管理のために監査ログが必要
      • workflow必要
    • 専用のsecret data management tool
      • 大規模組織のみ
      • infrastructureがcomplicateになる.コスト大
    • 推奨
      • SOPSなどの軽量encrypt toolのuse
  • (4) SOPSでのsecret dataのencrypt
    • SOPS(Secrets OPerationS): Mozilla projectによる
      • YAML, JSON, Binary fileと組み合わせて使用〇
      • 複数のencrypt backendが使える
    • secret dataの値のみencrypt
    • helm-secrets pluginでSOPSを使える
    • DGP protocol with public key
    • GnuPGのinstall
      • key fingerprint
    • SOPSのinstall
    • decrypt check: sops --decrypt xxxx.yaml
      • deployではSOPSをdecrypt modeで使用
        • → 平文fileは使用後必ず削除. Not check in
    • KMS backendも可能

作用

  • 必要なconfigやdataをapplicationと結びつける方法の理解

Ch11 Security and Backup

目的

  • kubernetesにおけるsecurityとaccess controllの仕組みの検討
  • 脆弱性をscanするための代表的toolやservice
  • kubernetesのdataとstateのbackup と復元方法

概要

  • (1) access controllとpermission
    • cluster別のaccess controll
      • cluster運用者/ application developerの2group化
      • 本番/ staging
    • RBAC(Role-Based Access Control) @kubernetes
      • 有効化
        • 確認: kubectl describe pod ...
    • Role
      • userが持つpermissionの特定のsetをroleが統制
      • namespaceやclusterを対象に
      • RoleBinding ObjectでuserとRoleを紐づけ
      • 加法的Permission
    • 必要なrole: defined roleのcluster-admin, edit, viewでおおよその要件は〇
    • cluster-admin ≒ root
      • not cluster 運用者やinternetにopenなservice accountには×
    • application専用のservice accountに対してRoleBinding Objectでroleを紐づける
    • CD toolにのみapplicationのdeployを許可
      • "edit" role
    • RBACの問題の対処方法
      • API serverのログでRBAC DENYを探す
  • (2) Security Scan
    • Clair: OSSのContainer scanner
    • Aqua Security: 商用. free版もある.(Micro Scanner)
      • kube-hunterというOSS toolもある
    • Anchore Engine: OSS, Container内すべての部品表を示す
  • (3) Backup
    • replication != backup
    • etcdのbackup: important
      • clustering, backup, replication
    • 必要なDeployのためのInfrastructure as Code
      • YAML ManifestかHelm Chartをversion management
        • → 宣言的管理
      • Manifest fileから変更を適用
      • clusterのsnapshotの作成
    • Veleno: OSS. clusterのstateと永続dataのbackupと復元
      • 使い方
      • 1つで完結したbackup
      • 手順書の作成と復元テスト at least once of month
      • scheduling
      • resourceとdataをcluster間で以降: lift&shiftもできる
  • (4) clusterのstatusの監視
    • kubectl
      • kubectl get
        • componentstatuses → scheduler, controller-manager, etcd
        • nodes → describeでdetailを見る
        • pods { --all-namespaces, -A }
      • kubectl top { nodes, pods }
        • → CPUとメモリの使用率,capacityを見る
    • cloud providerのconsole
    • kubernetes Dashboard
      • securityがimportant
      • never public internet
      • minimumの権限.kubectl proxy経由のaccess
      • 不要なら使わない
    • Weave Scope: clusterの監視と視覚化
    • kube-ops-view: cluster内の視覚化
    • node-problem-detector: kubernetesのaddon nodeの問題の検出

作用

  • 知識・思考・注意を要するcontinuous process: security

Ch12 kubernetes applicationのdeploy

目的

  • Manifest fileからapplicationを実行
  • application用のHelm Chartのbuild

概要

  • (1) HelmでのManifestのbuild
    • fileの保守 + 配布の問題を解決
      • 設定値や変数を生のmanifest fileから分離
      • ほかのapplicationやserviceへのdependencyも公開できる
    • Chartの内部校正
      • directory
      • Chart.yaml
        • Helm Chart名とversion: 必須
      • Values.yaml
        • userが修正可能
        • 自由な形式
        • chart内のどこからでも参照
    • Helm template
      • deployment.yamlとservice.yamlがtemplateになっている
      • 二重の中括弧: Goのtemplate文法
      • 変数での補完
        • loop, 式, 条件, functionも〇
      • doublequote → {{ ~ | quote }}
    • 依存関係の指定 → helm dependency update
  • (2) Helm ChartのDeploy
    • 変数の設定
      • 追加の値file. releaseにおける値の指定: helm install ~ --values...
        • 値の確認: helm inspect values
      • Helmでのapplicationの更新.何度でも〇
        • helm upgrade \<既存のdeploy>
    • 指定のversionへのrollback: helm rollback \ 1
      • rollforwardもrollbackで〇
      • helm-monitorによるauto rollback
    • Helm Chart Repositoryの作成
      • 普通はapplication独自のrepositoryに保存のため不要
    • Secret by SOPS in Helm Chart
      • secret dataを値fileにいれ,SOPSでencrypt
      • command, 適用手順
  • (3) Helm fileによるplural Chartの管理
    • clusterにinstallerする一式を単一のcommandでdeploy
    • helmfile.yaml
      • repositoriesに参照するHelm Chart Repositoryのリストを定義
      • releasesでdeployしたいapplicationを定義
      • 相対pathでdemo chartと値fileを指定
      • setで値の上書き
    • helmfileの適用: helmfile sync
      • CD pipelineでhelm sync を自動実行
    • 個別/helmfileは統一
      • → a single source of truthを守る
  • (4) 高度なManifest management tool
    • ksonnet: 計算やlogicが必要な大規模でcomplicateなdeployに〇
      • → projectが中止
      • Jsonnet: JSONの拡張.kubernetesJSONも〇
      • prototypeの導入: よく使われるManifest pattern
    • Kapitan
      • 設定値の階層DB: inventory
        • → 環境やapplicationに合わせて異なる値でmanifest patternを再利用
    • kustomize
      • plainなYAML
      • overlayでパッチとして適用
      • kustomize build ~ | kubectl apply -f ~
    • kompose
      • docker-compose.yml: 連携して機能する一連のContainerを定義, and deploy + containerの通信方法を定義
      • kubernetes Manifestに変換するtool
    • Ansible
      • 混合infrastructureの場合に強力
      • kubernetes clusterのinstallと設定
    • kubeval
      • Manifestの検証 to schema by version
      • CD pipelineへの追加が〇
      • Conftestも〇

作用

Ch13 Development workflow

目的

  • localのdevelopmentからkubernetes clusterへの更新のdeployまでのapplicationのlifecycleを扱う

概要

  • (1) development tool
    • Skaffold: development workflowのspeed up
      • skaffold.yamlにworkflowを定義
      • → skaffold command line toolの実行でpipeline start
    • Draft
      • Skaffoldと同様, by Azure team
      • Draft Pack: applicationが使用する言語に対応したDockerfileとHelm Chart
      • draft init && draft createで言語を特定
      • resourceの適用: draft up
    • Telepresence: local machineをremote clusterに参加させられる
    • Knative: 開発中. container化されたapplicationやserverless styleの機能を含めたあらゆるworkloadをkubernetesにdeploy
      • kubernetesとIstioの両方と統合
      • build processのsetup, deploy のautomate, Eventing
  • (2) deploy戦略
    • zero downtime deploy → userのrequestに対応するapplicationでは必要
    • Rolling Update( 0 downtime ) ←→ Recreate (high speed)
    • Deploy Manifestで定義
      • default: RollingUpdate
      • minReadySecondsでroll outをPodの安定まで待機. @RollingUpdate
    • MaxSurgeとmaxUnavailable: 基本は変える必要なし
    • blue green deploy
      • Serviceからtrafficを受信するPodを決定するため,Labelを使う
      • → Serviceのselectorのdeployment fieldに設定
      • blue, green, ... → rainbow deploy
    • canaria deploy → Istioを使うと高度なdeployが〇
  • (3) Helmでの移行
    • DBがかかわるときに必要な「移行」
      • Job Resourceで実現
        • Helmのhookで可能
    • Helmのhook: deploy中の処理準をcontroll
      • JobのAnnotationで指定
      • 失敗にも対応〇
      • pre-upgrade以外のhook
      • hookのchain化: plural hooks をchain化 by order
        • helm.sh/hook-weight propertyを使う

作用

  • kubernetes applicationの開発の高速化. by tools
  • 変更の本番環境へのrooloutが容易

Ch14 kubernetesでのCD

目的

  • CDとCDのkubernetes based cloud native 環境での実現
  • kubernetesと連携して動くCD pipeline
  • container化されたapplicationのpipelineの典型
      1. codeの変更をgit repositoryにpush
      1. build systemがbuild & test
      1. test ok → Container imageがContainer Registryに対してpublish
      1. new builded Containerがautomatically deploy to staging environment
      1. automatic acceptance test in staging environment
      1. tested Container image tobe deploy to production environment
  • deployの対象の成果物は〇Container, ×Source Code

対応

  • (1) CD tool
    • 既存のCDでも〇
    • Jenkins: Docker, kubectl, Helmなど〇
    • Drone: simple & 軽量.個々のビルドstepは1つのContainerの実行
    • Google Cloud Build with Google Cloud Platform
    • Concourse: Drone や Cloud builと同じく宣言的pipeline + 公式Helm Chartあり
    • Spinnaker: ebook for freeあり, by Netflix
    • GitLab CI
    • Codefresh: to feature branch
    • Azure Pipelines
  • (2) CDのComponent
    • 既存のCDにContainer用Componentの追加のe.g.
      • Docker Hub
      • Gitkube: self hosting. simple + 可搬性〇.setupも間t何
      • Flux: with GitOps extended
      • Keel ≒ Flux
  • (3) CD Pipeline のe.g. by Cloud Build
    • Google CloudとGKEのセットアップ
      • demo Repositoryのfork
      • Cloud Buildの導入
        • 1つのContainerの実行でbuild Pipelineの各stepが構成
      • Test用Containerのbuild
        • YAMLの説明,構成
        • docker image build --target build -tag demo:test
    • test run
    • application Containerのbuild → application Containerの作成
    • kubernetes Manifestの検証
    • imageのPublish
      • Git SHA tag @成果物 → Codeのsnapshotになる
    • triggerの作成: 監視target Git Repository, active化の条件, pipeline fileの指定
      • triggerのテスト
    • CD pipelineからのDeploy
      • kubernetes clusterへの認証情報の獲得
        • user definitionの置換
      • environment tagの追加
      • clusterへのdeploy
    • Deploy triggerの作成
      • tagのpushでtrigger
      • 代入変数
    • Build PipelineのOptimize
      • Container based CD Pipeline toolは,各stepのContainerをminimize
        • multi stage buildでoriginal custom imageをbuild

作用

  • applicationのためにCD Pipelineをsetup → 一貫した方法と高い信頼性でsoftwareを迅速にdeploy

Ch15 Observabilityと監視

目的

  • Observabilityと監視の関係
  • kubernetesでの監視,logging, metrics tracingの扱い

概要

  • (1) Observability
    • 監視を超えた概念
    • 監視
      • automatic 監視 @DevOps
    • blackbox監視
      • 複雑なdistributed systemとなるcloud native applicationの監視の観点
      • blackbox監視の限界: 「なぜか」に答えられない
    • up/down test
      • up: applicationの耐障害性と可用性をuptimeで測定
        • 99.9%: three nines
        • userの視点の計測が必要 ←→ nineの数
        • cloud native applicationは完全にupにはならない
          • gray failures problem
    • logging: 中央DBに集約 → problemのtrouble shoot
      • limit: developerのjudgeで作成.query difficult, signal/noise比が△
      • scale difficult
      • logを超えた方法が必要 → Metrics
    • metricsの導入
      • @application's metrics
        • 処理中のrequestの数, 毎分request処理数
        • request proceed中のerror数, request処理に要したaverage time
      • @Infrastructure's metrics
        • process/ContainerのCPU使用率
        • nodeやServerのdisc I/O activity
        • machine, cluster, load balancerのI/O network traffic
      • metrics: 「なぜか」の解決に有用
        • 予測にも使える
        • applicationを内部から監視
          • 実際の動作に基づいてシステムの隠れた側面に関するimportant informationを外に伝えられる
          • → 〇内からの監視/ ×reverse engineering
    • tracing @distributed system
      • 単一のuser requestのlifecycle全体を表す: requestの始点
    • metricsやtracingなど全体をカバーした用語としてのObservability: systemがなぜ正しく機能しないのかの理解
      • ←→ 監視: systemが正しく機能しているかどうか
      • dataについてのObservabilityもimportant
      • 不透明なsoftwareを測定
      • Codeのdevelopmentとproduction environmentでの大規模実行との間のloopを縮めるimportant tool culture
  • (2) Observability Pipeline
    • bufferによる統合 with standard metrics style by structured data

詳細

  • kubernetesでの監視
    • 外部からのblackbox check
      • 監視はuserの挙動を模倣
      • 外部からServiceの可用性を監視 vs 機能停止: Monitoring as a Service
      • 既存Serviceを使用する(安価 or freeのため)
    • 内部health check
      • user's happinessが観点となる
      • @Container
        • × Liveness check
        • 〇 Readiness check to dependency failures
          • circuit breaker pattern
      • elegant 劣化とする

作用

  • cloud native environmentで監視が目指すべき方向性
  • Observabilityの価値 with metrics

Ch16 kubernetesにおけるMetrics

目的

  • Metricsの扱い方
  • Metricsとは
    • 特定の対象を測定した数値
      • → 特定の瞬間における状況のsnapshot + 変化を示す
    • 時系列data by sampling
    • metrics値: Counter/Gauge
      • Counter: increment only or reset to 0.
        • 量の表現
      • Gauge: 増減〇. memory使用率など
        • 比率の表現
    • 異常やfailureの通知 + 機能状況の表示
      • → 「なぜか」の解決

概要

  • (1) 優れたmetricsのchoice
    • metricsの一部へのfocus
    • 要件ごとのobservabilityのためのmetrics pattern
      • service: RED pattern
        • serviceの示す性能
        • userの体験情報
        • ↑ これらの情報を得られる → 「observability data」のためのtop down 型の方法
        • REDは request駆動のsystem
          • Requestの数 → 1secあたりの受信request数
          • Errorの数 → エラーとなったrequestの割合
          • requestの持続期間(Duration) ≒ latency
              • 飽和度(saturation) → 4大signal
      • resource: USE pattern → 性能問題の分析とボトルネックの発見のためのbottom up型の方法 ←→ service
        • :systemの健全性のcheck, 高速で可視性高い
        • Utilization: 使用率
        • Saturation: 飽和度
        • Error
        • 対象は〇Resource/ ×Service
          • → system 性能のbottleneckの発見
            • e.g. CPU, disc, networkのIFやLink
    • business metrics
      • 加入者についてのdataの把握
        • funnel analysis
          • 解約率
          • 収益/顧客
          • help, support pageの有効性
          • System Status pageへのtraffic量
      • 共通のdatalakeを使用 in two or more groups
    • kubernetesのmetrics
      • cluster healthのmetrics
        • node数
        • nodeのhealth status
        • Pod数/node or Pod数 in all
        • Resource使用率, 割り当て by node or 全体
    • Deployのmetrics
      • Deployの数
      • Deployごとのreplicaの設定数
      • Deployごとの利用不可のreplicaの数
    • Containerに関するmetrics
      • Container/Podの数 by node or 全体
      • resource使用率 to Resource要求/Resource制限
      • ContainerのLiveness/Readiness
      • Container/Podのrestart 数
      • 各Containerのnetwork I/O traffic and error
    • applicationのmetrics
      • applicationの機能による
      • 性能や可用性の問題のため
      • applicationの実行内容,頻度,処理時間
      • とりあえず不明なら記録する
      • SLOやSLAに対するapplicationの性能も知る
    • runtimeのmetrics
      • processのrun statusを知る
        • 6こ
      • 性能の劣化やcrashについての診断に〇
  • (2) metricsの分析
    • data != information: informationにするための統計処理
    • 単純な平均のproblem: 大多数の人々の経験には不益
      • 外れ値の作用を受けやすい → アンスコムの通知例
        • ←→ 中央値
    • request driven → latencyのworst値がimportant → persentile(百分位数): p90, p50(中央値), p95, p99(e.g. →p.321)
    • worstがimportant
    • persentileのproblem
      • averageのaverage problem
      • 間違ったstateの監視がimportant
        • 閾値を超えたrequestの観測
  • (4) metricsのdashboardによるgraph化
    • metricsのgraph化 → dashboardにgroup化
    • すべてのserviceでstandard layout(e.g. → p.323)を使う
    • 全service横断でmetricsを集約して表示するmaster dashboard
    • あくまで,折れ線グラフというシンプルなstyleにする
    • vitalなinformationをinformation radiatorで表示
    • alertにかからないで壊れていくものをdashboardで表示
  • (5) metricsに基づくalert
    • alertのproblem
      • distributed systemは完全upにはならない
      • S/N比を高める必要
      • alertは,直ちに人間が対処すべきもの(という単純な事実)のみ表すべき
        • いずれ対処 → mail, chatでのalertでよい
      • OnCallの負担の軽減のimportance
      • alertは緊急かつimportantで対処可能なもののみ
        • → 一握りのmetricsに限定
        • → そうでないものは非同期通知
      • 要因についてのmetrics
  • (6) metrics managementのtool, Service
    • OSSが優秀
    • Prometheus: defact standard with kubernetes
      • scraping(収集) processでautomaticにmetricsを収集
      • Helmでcommand1つでkubernetes clusterにinstallできる
      • simpleな構成・仕組み
      • pull type の監視
      • Grafanaなどで,Prometheusで収集・保存した情報を活用
        • → 時系列dataのgraph化
      • Alertmanager
        • 重複排除 → alertのgroup化 → 通知serviceにrouting
      • Open metricsのbaseとなっている
    • その他のtools

作用

  • proper dataの収集 → proper方法で処理 → properなproblemの解決に活 → proper方法でvisualize → properな事項をproperな対象者にalert