Zenn
Closed13

CKAD取るぞ

Kubernetes
ckad
alkshmiralkshmir

limitRangeは、名前空間内に0個または1個存在して、デフォルトのリソース要求と上限を規定できるもの

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default: # this section defines default limits
      cpu: 500m
    defaultRequest: # this section defines default requests
      cpu: 500m
    max: # max and min define the limit range
      cpu: "1"
    min:
      cpu: 100m
    type: Container

ResourceQuotaは、名前空間内の総リソースを制限するリソース

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-resource
spec:
  hard:
    requests.cpu: 4
    requests.memory: 4Gi
    limits.cpu: 10
    limits.memory: 10Gi
alkshmiralkshmir

podがreadyになるには、

  • PodScheduled
  • Initialized
  • ContainersReady
  • Ready
    がTrueとなる必要がある
alkshmiralkshmir

--selectorはカンマ区切りするとAND条件になる
複数の--selectorを指定すると、OR条件になる

k get po --selector env=prod,bu=finance,tier=frontend
alkshmiralkshmir

kubectl rolloutのオプション

  • --revision: リビジョン番号を指定して情報を表示
$ kubectl rollout history deployment nginx --revision=1
deployment.extensions/nginx with revision #1
 
Pod Template:
 Labels:    app=nginx    pod-template-hash=6454457cdb
 Containers:  nginx:  Image:   nginx:1.16
  Port:    <none>
  Host Port: <none>
  Environment:    <none>
  Mounts:   <none>
 Volumes:   <none>

kubectl rollout undo deployment nginx --to-revision=1

でrevision 1に戻す

  • --record: change causeフィールドを記録する
alkshmiralkshmir

※StatefulSetは試験対象外
StatefulSetは、再起動しても一意なPod名が必要なアプリケーション(masterを特定する必要があるmysqlクラスター等)に使う。
ステートフルなだけなら、DeploymentにPVをマウントすれば実現できる。StatefulSetが必要なのは、同じサービス(ステートフルなPod群)の中で一意にPodを特定する必要がある場合である。

Headless Serviceは、サービス名だけでなく、Pod名まで指定するタイプのServiceである。
MySQLクラスターの例で言えば、書き込みはmasterでしかできないなどの制約があり、アクセス先のPodまで特定する必要があり、このような場合に用いる。
Serviceの定義でClusterIP: Noneにすれば使える

ステートフルならStatefulSetなんでしょ？って短絡的に覚えていたが、よく考えると上のような議論がある。

alkshmiralkshmir

StatefulSetのspec.template.spec.volumesにPVCを指定することができるが、その場合は複数のPodが同じPVCを介して同じPVをマウントする。（PVがReadWriteManyな場合のみマウントできる）

それぞれのレプリカが異なるPVCを使用して異なるPVをマウントしてほしい時は、StatefulSetのspec.volumeClaimTemplateにPVCのテンプレートを書く。

spec:
  # 略
  volumeClaimTemplate:
  - metadata:
      name: data-claim
    spec:
      accessModes:
        - ReadWriteOnce
      storageClassName: google-storage
      resources:
        requests:
          storage: 500Mi

claimModeはRetainであり、Podが終了した場合にはPVCを削除せずに新しく作ったPodに再割り当てする。

  • この機能はDeploymentにもあるのか？
alkshmiralkshmir

admission controllerはroleよりもより細かいレベルでアクセス制御したり、リクエストを変化させたりするための仕組み。
apiserverに来たリクエストは、認証→認可→Admission controller→実際の操作　の順で処理される。
デフォルトでついているadmission controller

  • AlwaysPullImages
  • DefaultStorageClass
  • EventRateLimit
  • NamespaceLifecycle

有効になっているadmission controllerをリスト

kube-apiserver -h | grep enable-admission-plugins

admission controllerを有効化するには、kube-apiserverの起動オプションに--enable-admission-pluginsオプションにカンマ区切りで使用するadmission pluginを指定すればいい。
無効化するには、--disable-admission-pluginsオプション

alkshmiralkshmir

  • Validating Admission Controllers
    リクエストの内容に応じてリクエストを拒否する

  • Mutating Admission Controllers
    リクエストの内容を書き換える

自分でadmission controllerを作るには、MutatingAdmissionWebhookとValidatingAdmissionWebhookを使う。
自前実装したwebhook serverにリクエストの内容を送り、リクエストの内容書き換えとリクエスト拒否・許可を行い、AdmissionReviewオブジェクトを返すもの。

Webhook serverはコンテナ化してdeployment + serviceとしてクラスタにデプロイする。
ValidatingWebhookConfigurationオブジェクトを作成することで、Validating Admission Webhookとして登録される。(Mutating Admission Webhookも同様)

apiVersion: admissionresistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "pod-policy.example.com"
webhooks:
  - name: "pod-policy.example.com"
    clientConfig:
      service:
        namespace: example-ns
        name: webhook-service
      caBundle: #ルート証明書リスト
    rules: 
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
        scope: "Namespaced"
alkshmiralkshmir

API Version

  • GA: /vX ex. v1
  • beta: /vXbetaY ex. v1beta1
  • alpha: /vXaplhaY ex. v1alpha1

Preferred version: kubectlで指定されるデフォルトバージョン

  • kubectl explain deploymentで確認できる(deploymentの場合)

Storage version: yaml指定するときのデフォルトバージョン

  • etcdに保存されるときのデフォルトバージョン
  • 基本的にPreferred versionと同じだが異なる場合がある

API deprecation policy

Kubernetes Deprecation Policy
APIエレメントは、APIグループのバージョンをインクリメントすることでのみ削除できる。

  • v1alpha1にあった/v1alpha1/hogeエンドポイントは、/v1alpha2以降でのみ消せる。

APIオブジェクトは、あるバージョンに存在しないRESTリソース全体を除いて、情報を失うことなく、与えられたリリースのAPIバージョン間でラウンドトリップできなければならない。

  • v1alpha2で新しいフィールドを追加したら、v1alpha1にも追加しなければならない

GA APIバージョンは非推奨としてマークされることがありますが、Kubernetesのメジャーバージョン内で削除されてはなりません。
ベータAPIバージョンは、導入後9ヶ月または3つのマイナーリリース（いずれか長い方）を超えない範囲で非推奨とされ、非推奨後9ヶ月または3つのマイナーリリース（いずれか長い方）を超えない範囲で非推奨とされます。
Alpha APIバージョンは、事前に非推奨であることを通知することなく、どのリリースでも削除される可能性があります。

alkshmiralkshmir

kubectl convert

kubectl convertコマンドを使って、新しいAPIバージョンのマニフェストに変換する

kubectl convert -f old.yaml --output-version <new-api-version>
alkshmiralkshmir

Custom Resource Definition (CRD)

フライトチケットを表すCRDの例

apiVersion: apiextentions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: flighttickets.flights.com
spec:
  scope: Namespaced
  group: flights.com #api group
  names:
    kind: FlightTicket
    singular: flighttickets # 単数形
    plural: flighttickets # 複数形
    shortNames: # 短縮系
      - ft
  versions:
    - name: v1
      served: true
      storage: true # storage version
  schema:
    openAPIV3Schema:
      # openapi v3 schemaを書く

Custom Controller

※Custom Controllerのコーディングは試験対象外

公式サンプル
https://github.com/kubernetes/sample-controller

Operator Framework

alkshmiralkshmir

受かっていたのでクローズ

勉強内容はCKAとほとんど被っていたが、より開発者よりの内容、つまりIngress, ServiceAccount, Job, CronJob, リソース制御とかが重点的だった。

このスクラップは2023/07/11にクローズされました