はじめに

本記事は、Certified Kubernetes Application Developer (CKAD)試験の対策をしている上で覚えておくべきだと感じたことをメモとして残しておくものです。
なお、CKA取得している知識を前提としたメモになります。ご了承ください。
CKA取得時の勉強メモはこちら

Readiness Probe and Liveness Probe

readinessProbe
- コンテナが準備できているかのチェック
livenessProbe
- コンテナが生存しているかのチェック

Jobs and CronJobs

Job
- spec.completions
  - 設定した回数分ジョブを完了するまでpodを作成し続ける
- spec.parallelism
  - 設定した数分podで並列処理する
CronJob
- spec.jobTemplate配下にJobで設定するspec配下を配置
- CronJob内でspecが3つになるので注意
- Jobでも設定できる項目はCronJobでも設定可能
両リソースともにkubectl createで作成可能

Stateful Sets

なぜStateful Setを使うのか？
- Deploymentでは各Podにランダムな数字が付与されるが、Stateful SetではPod名-0````Pod名-1のように序数が割り振られる。
- これにより通信に特定の名前が必要なワークロードや、特定の順番で立ち上がる必要があるワークロードを実現できる。
PersistentVolumeClaimをspec.template.spec.volumesを通常通り設定すると、各Podは同一のPVを割り当てる
- sts内のPod間でvolumesを共有したくない場合、spec.volumeClaimTemplatesにPVCのmetadata.*とspec.*の記載が必要

Headless Service

特手のPodに対してサブドメインとして機能するservice
- サブドメインの命名規則はpodname.headless-servicename.namespace.svc.cluseter-domain.example
Stateful Sets(sts)にHeadless Serviceを設定した場合
- stsは各podに固定の序数を付けるため、他リソースからsts内の特定のpodに対して通信が可能

Headless Service名	Headless Service 対象リソース	Podのhostname	機能するサブドメイン名一覧
hoge	Pod	pod	pod.hoge.default.svc.cluster.local
hoge	Devployment (replicas=2)	deploy	deploy.hoge.default.svc.cluster.local deploy.hoge.default.svc.cluster.local (2つのPodが同じサブドメインをもつ)
hoge	StatefulSet (replicas=2)	sts	sts-0.hoge.default.svc.cluster.local sts-1.hoge.default.svc.cluster.local

Admission Controllers

apiserverのリクエスト制御機能
- apiserverの引数--enable-admission-pluginsで設定される
- 無効化したいプラグインは--disable-admission-pluginsで設定
apiリクエストを認証→認可した後のフェーズでリクエストを許容するか決める
変異型(Mutating)と検証型(Validating)に分けられる
- 一般的に変異型→検証型の順番で検証される
admission controllerはwebhookとして外部のものを利用可能
- k8sクラスタ内にwebhook用podを作成して利用したり、外部のwebhookサーバを利用する
- MutatingAdmissionWebhookは順次処理
- ValidatingAdmissionWebhookは並列処理

API

クラスタ内でサポートされるapiバージョンを表示
- kubectl api-versions
リソースが属するGROUP、KIND、VERSIONを表示
- kubectl explain <resource>
  - v1とだけ表示されるリソースがあるがこれはcoreというGROUPに属しており省略可能なため書かれていない
パスの構成
- クラスタースコープの場合
  - /apis/GROUP/VERSION/*
- 名前空間スコープの場合
  - /apis/GROUP/VERSION/namespaces/NAMESPACE/*
- coreに属するグループの場合は/api
各階層毎の詳細
- /apis or /api
  - 固定
- /GROUP
  - /appsとか/storage.k8s.ioとか
  - kubectl api-versionsで出てくるAPIVERSIONヘッダー部参照
- /VERSION
  - /v1とか/v1beta3とか
  - kubectl api-versionsで出てくるAPIVERSIONヘッダー部参照

// example
/api/v1/namespaces
/api/v1/pods
/api/v1/namespaces/my-namespace/pods
/apis/apps/v1/deployments
/apis/apps/v1/namespaces/my-namespace/deployments
/apis/apps/v1/namespaces/my-namespace/deployments/my-deployment

apiリクエストを投げてbodyを見たい
- kubectl proxy & → curl http://localhost:8001/<apipath>で確認
  - & はバックグラウンドで実行

Custom Resource Definition (CRD)

前提：リソースとコントローラーは互いに1対1の関係
- 独自にリソースを定義できる
  - 対応するCustom Controllerがないと実際には何も影響を及ぼさない点に注意

Deployment Strategy

Blue Green
- k8s公式では用意されていないため手動で設定
- 例
  - Blue-Green環境それぞれにラベル:version=v1、version=v2を設定
  - serviceのselectorからversionを指定し向き先を変更
Canary
- k8s公式では用意されていないため手動で設定
- 例
  - 両環境に同じラベルを設定
  - serviceは両環境に設定した同じラベルを指定
  - primary環境のreplicas=5の場合はcanary環境にreplicas=1の新versionのdeploymentをデプロイ
  - 問題がなければ徐々にcanary環境のreplicasを増やしprimary環境のreplicasを減らす
- Istioを使えば詳細にルーティングの重みづけが可能

【対策メモ】Certified Kubernetes Application Developer (CKAD)試験

はじめに

Readiness Probe and Liveness Probe

Jobs and CronJobs

Stateful Sets

Headless Service

Admission Controllers

API

Custom Resource Definition (CRD)

Deployment Strategy