Extending Kubernetes Quiz
このクイズでは、Kubernetes の拡張メカニズムに関する概念的および実践的な知識を確認します。Custom Resource Definitions (CRD)、custom controllers、API extensions、webhooks、operator pattern などのトピックを扱います。
Multiple Choice Questions
- Kubernetes で custom resources を定義する最も一般的な方法は何ですか？
- A) ConfigMap を使用して resource schema を定義する
- B) CustomResourceDefinition (CRD) を作成する
- C) API server のコードを直接変更する
- D) Aggregation Layer を使用する
回答を表示
回答: B) CustomResourceDefinition (CRD) を作成する
解説: Kubernetes で custom resources を定義する最も一般的な方法は、CustomResourceDefinition (CRD) を作成することです。CRD は、新しい resource type を定義することで Kubernetes API を拡張できるメカニズムです。
CRDs を使用すると、次の利点があります。
- 既存の Kubernetes API server を変更せずに、新しい resource type を追加できます。
kubectlのような標準的な Kubernetes tools を使用して custom resources を管理できます。- resource validation、versioning、status subresources などの機能を活用できます。
CRD の例:
yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
image:
type: string
replicas:
type: integer
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct他の選択肢の問題点:
- ConfigMaps は設定データを保存するために使用され、API extensions には適していません。
- API server のコードを直接変更するのは複雑で、保守が難しく、upgrade 時に問題を引き起こす可能性があります。
- Aggregation Layer も custom resources を定義する別の方法ですが、別個の API server を実装する必要があるため、CRDs より複雑です。
- Kubernetes Operator の主な目的は何ですか？
- A) cluster nodes の resource usage を最適化する
- B) 複雑な applications の operational knowledge を自動化された software にエンコードする
- C) Kubernetes API server の performance を向上させる
- D) cluster networking functionality を拡張する
回答を表示
回答: B) 複雑な applications の operational knowledge を自動化された software にエンコードする
解説: Kubernetes Operator の主な目的は、複雑な applications の operational knowledge を自動化された software にエンコードすることです。operator pattern は、人間の operator が複雑な applications を管理する方法を software として実装したものです。
operators の主な特徴:
- custom resources と custom controllers を組み合わせて、application 固有の logic を実装します。
- application deployment、upgrades、backup、recovery、scaling などの operational tasks を自動化します。
- application state を継続的に監視し、desired state に調整します。
- domain knowledge をコード化し、複雑な applications の declarative management を可能にします。
operators の一般的な use cases:
- databases の自動管理（例: PostgreSQL、MySQL、MongoDB）
- messaging systems の deployment と configuration（例: Kafka、RabbitMQ）
- monitoring systems の setup と maintenance（例: Prometheus）
- service meshes の管理（例: Istio）
Operator 例 - Prometheus Operator:
yaml
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus
spec:
serviceAccountName: prometheus
replicas: 2
version: v2.35.0
serviceMonitorSelector:
matchLabels:
team: frontend
resources:
requests:
memory: 400Miこの単純な declarative configuration により、Prometheus Operator は次のような複雑な tasks を自動的に処理します。
- Prometheus servers の deployment
- configuration files の作成と管理
- service monitoring targets の自動検出
- high availability setup
- storage management
- upgrade coordination
他の選択肢は operators の主な目的ではありません。
- Resource usage optimization は HPA (Horizontal Pod Autoscaler)、VPA (Vertical Pod Autoscaler) などの役割です。
- API server performance の向上は operators の主な目的ではありません。
- networking functionality の拡張は CNI plugins または service meshes の役割です。
- Kubernetes における Admission Webhooks の主な機能は何ですか？
- A) API server の authentication を処理する
- B) resource の作成または変更 requests を intercept し、それらを validate または modify する
- C) cluster events を監視して alerts を送信する
- D) external systems との integration のための APIs を提供する
回答を表示
回答: B) resource の作成または変更 requests を intercept し、それらを validate または modify する
解説: Kubernetes における Admission Webhooks の主な機能は、resource の作成または変更 requests を intercept し、それらを validate または modify することです。Admission webhooks は、Kubernetes API server が requests を persistent storage (etcd) に保存する前に intercept するメカニズムを提供します。
admission webhooks には 2 種類があります。
Validating Webhook:
- resource の create、update、delete requests を validate します。
- requests を allow または deny できますが、modify はできません。
- policy enforcement、security checks、configuration validation などに使用されます。
Mutating Webhook:
- resource の create および update requests を validate し、modify できます。
- defaults の設定、sidecar containers の injection、labels の追加などに使用されます。
- validating webhooks より前に実行されます。
Admission webhook configuration 例:
yaml
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: pod-policy-validator
webhooks:
- name: pod-policy.example.com
clientConfig:
service:
namespace: webhook-namespace
name: webhook-service
path: "/validate-pods"
caBundle: <base64-encoded-ca-cert>
rules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["pods"]
scope: "Namespaced"
admissionReviewVersions: ["v1", "v1beta1"]
sideEffects: None
timeoutSeconds: 5admission webhooks の一般的な use cases:
- security policies の enforcement（例: privileged containers の禁止）
- resource requests と limits の enforcement
- sidecar containers の自動 injection（例: Istio）
- labels と annotations の自動追加
- image registries の制限
- namespace-based policies の適用
他の選択肢の問題点:
- API server の authentication を処理するのは Authentication Plugins の役割です。
- cluster events の監視と alerts の送信は event listeners または monitoring tools の役割です。
- external systems との integration のための APIs を提供することは API extensions の一般的な目的ですが、admission webhooks の主な機能ではありません。
- Kubernetes API server における Aggregation Layer の主な目的は何ですか？
- A) API server performance を最適化する
- B) 複数の API servers を単一の API server に統合する
- C) custom API servers を main API server に統合して API を拡張する
- D) cluster 内で service discovery を提供する
回答を表示
回答: C) custom API servers を main API server に統合して API を拡張する
解説: Kubernetes API server における Aggregation Layer の主な目的は、custom API servers を main API server に統合して API を拡張することです。これは Kubernetes API を拡張する別の方法を提供し、CRDs よりも強力な機能を提供しますが、より複雑です。
Aggregation Layer の主な特徴:
- custom API servers を Kubernetes API server の URL space に統合します。
- custom API servers は独自の storage、business logic、API versions などを持つことができます。
- main API server は requests を適切な custom API server に proxy します。
- authentication と authorization は main API server によって処理されます。
Aggregation Layer が使用される cases:
- 複雑な validation logic が必要な場合
- custom storage backend が必要な場合
- 既存 APIs とは異なる behavior が必要な場合
- resource transformation または special state calculation が必要な場合
APIService resource 例:
yaml
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
name: v1alpha1.metrics.k8s.io
spec:
service:
name: metrics-server
namespace: kube-system
group: metrics.k8s.io
version: v1alpha1
insecureSkipTLSVerify: true
groupPriorityMinimum: 100
versionPriority: 100この configuration は、metrics.k8s.io/v1alpha1 API group への requests を kube-system namespace 内の metrics-server service に routing します。
Aggregation Layer を使用する実例:
- metrics-server: node と pod の resource usage metrics を提供します
- service-catalog: external service brokers との integration
- custom-metrics-apiserver: HPA 用の custom metrics を提供します
他の選択肢の問題点:
- Aggregation Layer は API server performance を最適化するためのものではありません。
- 複数の API servers を 1 つに統合するという説明は正確ではありません。Aggregation Layer は複数の API servers を単一の URL space に統合しますが、servers は別々に実行されます。
- Aggregation Layer は service discovery を提供しません。それは Kubernetes Services の役割です。
- Kubernetes における Custom Controller の主な役割は何ですか？
- A) cluster nodes の resource usage を監視する
- B) custom resources の state を観察し、desired state に reconcile する
- C) API server requests の authentication と authorization を処理する
- D) cluster networking を管理する
回答を表示
回答: B) custom resources の state を観察し、desired state に reconcile する
解説: Kubernetes における Custom Controller の主な役割は、custom resources の state を観察し、desired state に reconcile することです。Controllers は、Kubernetes の中核的な operational pattern である「reconciliation loop」を実装し、system の actual state を desired state に継続的に調整します。
custom controllers の主な特徴:
- 特定の resource types（通常は CRDs で定義された custom resources）を watch します。
- resource change events に反応し、business logic を実行します。
- resources の actual state を desired state に調整する tasks を実行します。
- 現在の state を反映するために resources の status field を更新します。
custom controllers の一般的な components:
- Informer: Kubernetes API server を watch し、resource change events を受け取ります。
- Work Queue: 処理される events を保存および管理します。
- Reconciler: resources の desired state と actual state を比較し、必要な tasks を実行します。
- Client: Kubernetes API とやり取りして resources を create、update、delete します。
Custom controller 例 - simple reconcile function:
go
func (c *Controller) reconcile(key string) error {
// Split key into namespace and name
namespace, name, err := cache.SplitMetaNamespaceKey(key)
if err != nil {
return err
}
// Get custom resource
instance, err := c.customResourceLister.CustomResources(namespace).Get(name)
if errors.IsNotFound(err) {
// Resource deleted - perform cleanup
return nil
}
if err != nil {
return err
}
// Check resource state and perform necessary tasks
// e.g., create sub-resources, integrate with external systems, update status, etc.
// Update status
instanceCopy := instance.DeepCopy()
instanceCopy.Status.Phase = "Reconciled"
_, err = c.customResourceClient.CustomResources(namespace).UpdateStatus(instanceCopy)
return err
}custom controllers の一般的な use cases:
- 複雑な application deployment と management の自動化
- external systems との integration（例: cloud resource provisioning）
- backup と recovery processes の自動化
- 高度な deployment strategies の実装（例: canary deployments、blue-green deployments）
他の選択肢の問題点:
- cluster nodes の resource usage を監視するのは metrics-server または Prometheus などの monitoring tools の役割です。
- API server requests の authentication と authorization を処理するのは authentication and authorization plugins の役割です。
- cluster networking を管理するのは CNI plugins または network controllers の役割です。
- Kubernetes で CRDs (CustomResourceDefinitions) の validation schemas を定義するために使用される format は何ですか？
- A) JSON Schema
- B) XML Schema
- C) OpenAPI v3 Schema
- D) GraphQL Schema
回答を表示
回答: C) OpenAPI v3 Schema
解説: Kubernetes で CRDs (CustomResourceDefinitions) の validation schemas を定義するために使用される format は OpenAPI v3 Schema です。この schema は custom resources の structure と field types を定義し、API server が resource creation と update requests を validate するために使用されます。
CRD validation schema の例:
yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
required: ["spec"]
properties:
spec:
type: object
required: ["cronSpec", "image"]
properties:
cronSpec:
type: string
pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
image:
type: string
replicas:
type: integer
minimum: 1
maximum: 10
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ctこの例では、openAPIV3Schema field が次の validation rules を定義しています。
specfield は必須です。specの中では、cronSpecとimagefields が必須です。cronSpecは string で、cron expression pattern に従う必要があります。imageは string です。replicasは integer で、1 から 10 の間である必要があります。
OpenAPI v3 Schema はさまざまな validation features を提供します。
- required fields の指定
- data type validation（string、number、boolean、object、array など）
- string pattern validation（regular expressions）
- number range validation（minimum、maximum）
- array length validation
- enum value validation
- nested object structure definition
他の選択肢の問題点:
- JSON Schema は OpenAPI の基礎ですが、Kubernetes は具体的に OpenAPI v3 Schema を使用します。
- XML Schema は Kubernetes API では使用されません。
- GraphQL Schema は GraphQL APIs で使用されますが、Kubernetes API では使用されません。
- Kubernetes の custom resources で status subresource を有効にする主な利点は何ですか？
- A) resource creation が速くなる
- B) spec と status updates の分離、および RBAC control
- C) automatic backup と recovery features
- D) resource version management の簡素化
回答を表示
回答: B) spec と status updates の分離、および RBAC control
解説: Kubernetes の custom resources で status subresource を有効にする主な利点は、spec と status updates の分離、および RBAC (Role-Based Access Control) を通じて access を制御できることです。
status subresource を有効にする利点:
Separation of Concerns:
specfield は users が指定する desired state を定義します。statusfield は controllers が観察した actual state を報告します。- この分離により、users と controllers の責任が明確になります。
RBAC Control:
- status update permissions は controllers のみに付与し、通常の users には read-only permissions を与えることができます。
- これにより、status information の不正な変更を防止できます。
Conflict Prevention:
- user が
specを更新している間に controller がstatusを更新しても、conflict は発生しません。 - これは 2 つの fields が別々の API requests を通じて更新されるためです。
- user が
Scale Subresource Support:
- status subresource を有効にすると、scale subresource も有効化できます。
- これにより、HPA (Horizontal Pod Autoscaler) のような標準的な Kubernetes scaling tools を使用できます。
CRD で status subresource を有効にする例:
yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
subresources:
status: {} # Enable status subresource
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
# Spec field definitions...
status:
type: object
properties:
# Status field definitions...
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTabcontroller からの status update の例:
go
// Update status only
statusUpdate := &v1alpha1.MyResource{}
statusUpdate.Name = instance.Name
statusUpdate.Namespace = instance.Namespace
statusUpdate.Status.Phase = "Running"
statusUpdate.Status.Message = "Resource is running"
_, err = c.clientset.MyGroup().MyResources(namespace).UpdateStatus(statusUpdate)他の選択肢の問題点:
- status subresource は resource creation speed を向上させません。
- automatic backup と recovery features は提供しません。
- resource version management は CRD の
versionsfield を通じて処理され、status subresource とは直接関係ありません。
- Kubernetes における Webhook Conversion の主な目的は何ですか？
- A) API requests を external services に route する
- B) custom resources の異なる versions 間の conversion を処理する
- C) authentication tokens を異なる formats に変換する
- D) log data を structured formats に変換する
回答を表示
回答: B) custom resources の異なる versions 間の conversion を処理する
解説: Kubernetes における Webhook Conversion の主な目的は、custom resources の異なる versions 間の conversion を処理することです。この機能は CRDs の multiple versions をサポートし、versions 間のスムーズな migration を可能にします。
webhook conversion の主な特徴:
Multi-Version Support:
- CRDs は複数の API versions を同時にサポートできます（例: v1alpha1、v1beta1、v1）。
- 各 version は異なる schemas と fields を持つことができます。
Automatic Conversion:
- API server は client が request した version と storage version の間の conversion を自動的に処理します。
- conversion webhook はこの process で custom conversion logic を提供します。
Storage Version Independence:
- storage version が変更されても、以前の versions を使用する clients は引き続き動作できます。
- webhook は old versions と new versions の間の bidirectional conversion を処理します。
CRD における conversion webhook configuration の例:
yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
# v1 schema definition...
- name: v1beta1
served: true
storage: false
schema:
openAPIV3Schema:
# v1beta1 schema definition...
conversion:
strategy: Webhook
webhook:
clientConfig:
service:
namespace: webhook-system
name: crd-conversion-webhook
path: /convert
caBundle: <base64-encoded-ca-cert>
conversionReviewVersions: ["v1", "v1beta1"]
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTabconversion webhook server implementation の例:
go
func (s *WebhookServer) ServeConvert(w http.ResponseWriter, r *http.Request) {
var body []byte
if r.Body != nil {
if data, err := ioutil.ReadAll(r.Body); err == nil {
body = data
}
}
// Decode ConversionReview request
convertReview := v1.ConversionReview{}
if err := json.Unmarshal(body, &convertReview); err != nil {
// Error handling
return
}
// Perform conversion logic
if convertReview.Request.DesiredAPIVersion == "stable.example.com/v1" {
// v1beta1 -> v1 conversion
for i, obj := range convertReview.Request.Objects {
v1beta1Obj := &v1beta1.CronTab{}
if err := json.Unmarshal(obj.Raw, v1beta1Obj); err != nil {
// Error handling
return
}
// Conversion logic
v1Obj := &v1.CronTab{
Spec: v1.CronTabSpec{
CronSpec: v1beta1Obj.Spec.Cron, // Field name change
Image: v1beta1Obj.Spec.Image,
Replicas: v1beta1Obj.Spec.Replicas,
},
}
// Encode converted object
raw, err := json.Marshal(v1Obj)
if err != nil {
// Error handling
return
}
convertReview.Response.ConvertedObjects = append(
convertReview.Response.ConvertedObjects,
runtime.RawExtension{Raw: raw},
)
}
} else {
// v1 -> v1beta1 conversion
// Similar logic...
}
// Set response
convertReview.Response.UID = convertReview.Request.UID
convertReview.Response.Result.Status = "Success"
// Send response
w.Header().Set("Content-Type", "application/json")
json.NewEncoder(w).Encode(convertReview)
}他の選択肢の問題点:
- API requests を external services に routing するのは API aggregation の役割です。
- authentication tokens の conversion は authentication plugins の役割です。
- log data の conversion は logging systems の役割です。
- 次のうち、Kubernetes operators の開発を支援する framework ではないものはどれですか？
- A) Operator Framework
- B) Kubebuilder
- C) Metacontroller
- D) Kubespray
回答を表示
回答: D) Kubespray
解説: Kubespray は Kubernetes operators の開発を支援する framework ではありません。Kubespray は Ansible playbooks を使用して Kubernetes clusters を deploy および manage するための tool です。cluster installation と configuration に重点を置いており、operator development とは関係ありません。
Kubernetes operator development のための実際の frameworks は次のとおりです。
Operator Framework:
- Red Hat によって開発された operator development toolkit
- 主な components:
- Operator SDK: Operator scaffolding と development tools
- Operator Lifecycle Manager (OLM): Operator installation と upgrade management
- Operator Metering: Operator usage reporting
- Go、Ansible、Helm-based operator development をサポート
Kubebuilder:
- Kubernetes SIG (Special Interest Group) によって開発された framework
- Go で controllers を開発するための SDK
- code generation、CRD management、testing tools を提供
- controller-runtime library に基づく
Metacontroller:
- lightweight webhook-based operator framework
- さまざまな languages で controller logic を実装可能
- declarative controller definition
- simple controllers を素早く開発するのに適している
各 framework の feature comparison:
| Framework | Primary Language | Complexity | Features |
|---|---|---|---|
| Operator Framework | Go, Ansible, Helm | Medium-High | Comprehensive toolkit, various development options |
| Kubebuilder | Go | Medium | Standardized patterns, code generation tools |
| Metacontroller | Language-independent | Low | Webhook-based, simple implementation |
Operator development example (using Kubebuilder):
bash
# Initialize project
kubebuilder init --domain example.com --repo github.com/example/my-operator
# Create API
kubebuilder create api --group apps --version v1alpha1 --kind MyApp
# Implement controller (edit controller.go file)
# Create CRD and deploy controller
make install
make deploy他の選択肢の説明:
- Operator Framework は Red Hat の包括的な operator development toolkit です。
- Kubebuilder は Kubernetes SIG によって開発された Go-based controller development framework です。
- Metacontroller は lightweight webhook-based operator framework です。
- Kubernetes における Custom Resource Definitions (CRD) と Aggregated APIs の主な違いは何ですか？
- A) CRDs は versioning をサポートしないが、Aggregated APIs はサポートする
- B) CRDs は validation schemas をサポートしないが、Aggregated APIs はサポートする
- C) CRDs は実装が簡単だが flexibility が限られており、Aggregated APIs は実装が複雑だがより高い flexibility を提供する
- D) CRDs は cluster-scoped resources のみをサポートし、Aggregated APIs は namespace-scoped resources のみをサポートする
回答を表示
回答: C) CRDs は実装が簡単だが flexibility が限られており、Aggregated APIs は実装が複雑だがより高い flexibility を提供する
解説: Kubernetes における Custom Resource Definitions (CRD) と Aggregated APIs の主な違いは、implementation complexity と flexibility のバランスです。CRDs は実装が簡単ですが flexibility が限られており、Aggregated APIs は実装が複雑ですがより高い flexibility を提供します。
CRDs (CustomResourceDefinitions) の特徴:
- Simple implementation: 単一の YAML file で新しい API resources を定義できます。
- Uses existing API server: 別個の API server を実装する必要がありません。
- Limited flexibility:
- Storage は etcd に限定されます。
- default API server の behavior を継承します。
- 複雑な validation または conversion logic の実装が難しいです。
- Extension through webhooks: 一部の functionality は validating webhooks、conversion webhooks などを通じて拡張できます。
Aggregated APIs の特徴:
- Complex implementation: 別個の API server を開発し、deploy する必要があります。
- High flexibility:
- custom storage backends を使用できます
- 複雑な business logic を実装できます
- custom authentication と authorization logic を実装できます
- special state calculation と conversion logic を実装できます
- Full API server functionality: 標準的な Kubernetes API server のすべての features を活用できます。
Selection Criteria:
| Criteria | Choose CRD | Choose Aggregated API |
|---|---|---|
| Implementation complexity | Low - Simple YAML definition | High - Requires separate API server development |
| Development time | Short - Can implement in minutes | Long - Requires complete API server development |
| Maintenance | Easy - Managed by existing API server | Difficult - Requires maintaining separate service |
| Storage options | etcd only | Custom storage backends possible |
| Business logic | Limited - Implement via controllers | Flexible - Can implement directly in API server |
| Performance | Generally good | Custom optimization possible |
| Use cases | Simple CRUD operations, standard patterns | Complex API behavior, special validation/conversion |
Example Scenarios:
CRDs に適した cases:
- simple application configuration management
- main requirements としての basic CRUD operations
- rapid prototyping と development
Aggregated APIs に適した cases:
- external databases との integration
- 複雑な data transformation と validation
- special authentication mechanisms が必要な場合
- high-performance または special-purpose APIs
他の選択肢の問題点:
- CRDs は versioning をサポートします（A は誤り）。
- CRDs は OpenAPI v3 Schema を通じて validation schemas をサポートします（B は誤り）。
- CRDs と Aggregated APIs はどちらも cluster-scoped と namespace-scoped resources をサポートします（D は誤り）。
Short Answer Questions
- CustomResourceDefinition (CRD) を使用して custom resources を定義する方法と、それらの resources に validation rules を設定する方法を説明してください。
回答を表示
回答:
CustomResourceDefinition (CRD) の定義方法:
CRD は、Kubernetes API を拡張して新しい resource types を定義するメカニズムです。CRD を作成すると、新しい RESTful API endpoint が作成され、kubectl のような標準 tools を使用してその resource を管理できます。
1. Basic CRD Structure:
yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: <plural>.<group> # e.g., crontabs.stable.example.com
spec:
group: <api-group> # e.g., stable.example.com
names:
kind: <kind-name> # e.g., CronTab
plural: <plural-name> # e.g., crontabs
singular: <singular-name> # e.g., crontab
shortNames: # optional
- <short-name> # e.g., ct
scope: Namespaced # or Cluster
versions:
- name: <version> # e.g., v1
served: true # whether to serve via API server
storage: true # whether this is the storage version
schema:
openAPIV3Schema:
# schema definition2. Validation Rules の設定:
CRDs の validation rules は openAPIV3Schema field を通じて設定します。この schema は OpenAPI v3 format に従い、resources の structure と field types を定義します。
Basic Validation Rules Example:
yaml
schema:
openAPIV3Schema:
type: object
required: ["spec"]
properties:
spec:
type: object
required: ["cronSpec", "image"]
properties:
cronSpec:
type: string
pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
image:
type: string
replicas:
type: integer
minimum: 1
maximum: 10
default: 13. Advanced Validation Features:
OpenAPI v3 Schema はさまざまな validation features を提供します。
Required fields: field names を
requiredarray に追加しますyamlrequired: ["fieldName1", "fieldName2"]Data types:
typefield を使用して data types を指定しますyamltype: string | number | integer | boolean | array | objectString constraints: string length と patterns を validate します
yamlminLength: 3 maxLength: 64 pattern: '^[a-z0-9]([-a-z0-9]*[a-z0-9])?$'Number constraints: number ranges を validate します
yamlminimum: 0 maximum: 100 multipleOf: 5Array constraints: array length と items を validate します
yamlminItems: 1 maxItems: 10 uniqueItems: true items: type: stringEnum values: allowed value list を指定します
yamlenum: ["value1", "value2", "value3"]Default values: fields の default values を指定します
yamldefault: "default-value"Additional properties: additional properties を許可するかどうかを制御します
yamladditionalProperties: false
4. Complete CRD Example:
yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
required: ["spec"]
properties:
spec:
type: object
required: ["cronSpec", "image"]
properties:
cronSpec:
type: string
pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
image:
type: string
replicas:
type: integer
minimum: 1
maximum: 10
default: 1
status:
type: object
properties:
active:
type: boolean
lastScheduleTime:
type: string
format: date-time
subresources:
status: {} # Enable status subresource
additionalPrinterColumns:
- name: Schedule
type: string
description: The cron schedule
jsonPath: .spec.cronSpec
- name: Image
type: string
description: The image to use
jsonPath: .spec.image
- name: Age
type: date
jsonPath: .metadata.creationTimestamp
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct5. CRD の適用と使用:
bash
# Apply CRD
kubectl apply -f crontab-crd.yaml
# Create custom resource
cat <<EOF | kubectl apply -f -
apiVersion: stable.example.com/v1
kind: CronTab
metadata:
name: my-crontab
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 3
EOF
# View custom resources
kubectl get crontabs
kubectl get ct # Using short name6. Validation Rules のテスト:
無効な values を持つ resource を作成すると、validation errors が発生します。
bash
cat <<EOF | kubectl apply -f -
apiVersion: stable.example.com/v1
kind: CronTab
metadata:
name: invalid-crontab
spec:
cronSpec: "invalid-cron-spec" # Pattern mismatch
image: my-cron-image
replicas: 20 # Exceeds maximum
EOFこの command は次のような errors を返します。
Error from server (Invalid): error when creating "STDIN": admission webhook "validate-crontab.example.com" denied the request:
- spec.cronSpec: Invalid value: "invalid-cron-spec": does not match pattern '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
- spec.replicas: Invalid value: 20: must be less than or equal to 107. Best Practices:
- 明確で詳細な schema definitions
- required fields を明示的に指定する
- 適切な default values を提供する
- string patterns と number ranges を制限する
- status subresource を有効にする
- additional printer columns を設定する
- versioning strategy を確立する
- Kubernetes Operator Pattern の core concepts と、operators を実装する一般的な methods を説明してください。
回答を表示
回答:
Kubernetes Operator Pattern の Core Concepts:
operator pattern は、application 固有の operational knowledge を software にエンコードして複雑な applications を自動的に管理する Kubernetes extension mechanism です。この pattern は、人間の operator が複雑な systems を管理する方法を模倣します。
1. Core Concepts:
- Declarative Management: users が desired state を宣言し、operator が current state を desired state に調整します。
- Encoding Domain Knowledge: 特定の applications に関する operational knowledge と best practices をコード化します。
- Reconciliation Loop: actual state を継続的に観察し、desired state に調整します。
- Custom Resources: application 固有の configuration と state を保存するために使用されます。
- Controllers: custom resources の変更を watch し、必要な tasks を実行します。
2. Operators の Common Functions:
- Installation and Upgrades: application components を deploy し、versions を upgrade する
- Automatic Recovery: failures を検出し、recovery tasks を実行する
- Backup and Restore: data backup と restore processes を自動化する
- Scaling: workload requirements に基づく automatic expansion と contraction
- Configuration Management: application 固有の configuration changes を処理する
- Operations Automation: routine operational tasks（例: database compaction、index rebuilding）を自動化する
Operators の実装方法:
1. Operator SDK の使用:
Operator SDK は Red Hat の Operator Framework の一部であり、operator development を簡素化する tool です。
bash
# Install Operator SDK
curl -LO https://github.com/operator-framework/operator-sdk/releases/download/v1.25.0/operator-sdk_linux_amd64
chmod +x operator-sdk_linux_amd64
sudo mv operator-sdk_linux_amd64 /usr/local/bin/operator-sdk
# Create Go-based operator project
operator-sdk init --domain example.com --repo github.com/example/my-operator
# Create API
operator-sdk create api --group apps --version v1alpha1 --kind MyApp --resource --controller
# Create CRD
make manifests
# Build and deploy operator
make docker-build docker-push
make deploy2. Kubebuilder の使用:
Kubebuilder は Kubernetes SIG によって開発された framework で、controller development のための tools を提供します。
bash
# Install Kubebuilder
curl -L https://go.kubebuilder.io/dl/latest/$(go env GOOS)/$(go env GOARCH) | tar -xz -C /tmp/
sudo mv /tmp/kubebuilder_*/bin/kubebuilder /usr/local/bin/
# Initialize project
kubebuilder init --domain example.com --repo github.com/example/my-operator
# Create API
kubebuilder create api --group apps --version v1alpha1 --kind MyApp
# Create CRD and deploy controller
make install
make deploy3. Controller Implementation:
operator の中核は reconciliation function です。この function は custom resources の current state を観察し、必要な tasks を実行します。
go
// Reconcile function example
func (r *MyAppReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
log := r.Log.WithValues("myapp", req.NamespacedName)
// Get custom resource
var myApp appsv1alpha1.MyApp
if err := r.Get(ctx, req.NamespacedName, &myApp); err != nil {
if errors.IsNotFound(err) {
// Resource deleted - perform cleanup
return ctrl.Result{}, nil
}
// Error occurred
return ctrl.Result{}, err
}
// 1. Check if required resources exist
deployment := &appsv1.Deployment{}
err := r.Get(ctx, types.NamespacedName{Name: myApp.Name, Namespace: myApp.Namespace}, deployment)
if errors.IsNotFound(err) {
// Create deployment if it doesn't exist
deployment = r.deploymentForMyApp(&myApp)
log.Info("Creating a new Deployment", "Deployment.Namespace", deployment.Namespace, "Deployment.Name", deployment.Name)
if err := r.Create(ctx, deployment); err != nil {
log.Error(err, "Failed to create new Deployment")
return ctrl.Result{}, err
}
// Deployment creation successful
return ctrl.Result{Requeue: true}, nil
} else if err != nil {
log.Error(err, "Failed to get Deployment")
return ctrl.Result{}, err
}
// 2. Check if deployment is in desired state
size := myApp.Spec.Size
if *deployment.Spec.Replicas != size {
deployment.Spec.Replicas = &size
if err := r.Update(ctx, deployment); err != nil {
log.Error(err, "Failed to update Deployment")
return ctrl.Result{}, err
}
// Deployment update successful
return ctrl.Result{Requeue: true}, nil
}
// 3. Update status
if myApp.Status.AvailableReplicas != deployment.Status.AvailableReplicas {
myApp.Status.AvailableReplicas = deployment.Status.AvailableReplicas
if err := r.Status().Update(ctx, &myApp); err != nil {
log.Error(err, "Failed to update MyApp status")
return ctrl.Result{}, err
}
}
return ctrl.Result{}, nil
}
// Deployment creation function
func (r *MyAppReconciler) deploymentForMyApp(m *appsv1alpha1.MyApp) *appsv1.Deployment {
ls := labelsForMyApp(m.Name)
replicas := m.Spec.Size
dep := &appsv1.Deployment{
ObjectMeta: metav1.ObjectMeta{
Name: m.Name,
Namespace: m.Namespace,
},
Spec: appsv1.DeploymentSpec{
Replicas: &replicas,
Selector: &metav1.LabelSelector{
MatchLabels: ls,
},
Template: corev1.PodTemplateSpec{
ObjectMeta: metav1.ObjectMeta{
Labels: ls,
},
Spec: corev1.PodSpec{
Containers: []corev1.Container{{
Image: m.Spec.Image,
Name: "myapp",
Ports: []corev1.ContainerPort{{
ContainerPort: 8080,
Name: "http",
}},
}},
},
},
},
}
// Set owner reference
ctrl.SetControllerReference(m, dep, r.Scheme)
return dep
}4. Custom Resource Definition:
operator によって管理される custom resources の API を定義します。
go
// MyApp API
type MyAppSpec struct {
// Application image
Image string `json:"image"`
// Number of replicas
Size int32 `json:"size"`
// Configuration options
Config map[string]string `json:"config,omitempty"`
}
type MyAppStatus struct {
// Number of available replicas
AvailableReplicas int32 `json:"availableReplicas"`
// Last update time
LastUpdateTime metav1.Time `json:"lastUpdateTime,omitempty"`
// Status message
Message string `json:"message,omitempty"`
}
// MyApp resource
// +kubebuilder:object:root=true
// +kubebuilder:subresource:status
// +kubebuilder:printcolumn:name="Replicas",type=integer,JSONPath=`.spec.size`
// +kubebuilder:printcolumn:name="Available",type=integer,JSONPath=`.status.availableReplicas`
// +kubebuilder:printcolumn:name="Age",type=date,JSONPath=`.metadata.creationTimestamp`
type MyApp struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty"`
Spec MyAppSpec `json:"spec,omitempty"`
Status MyAppStatus `json:"status,omitempty"`
}5. Ansible または Helm-Based Operators:
Operator SDK は Go に加えて、Ansible または Helm を使用した operator development もサポートしています。
Ansible-based operator:
bash
# Create Ansible-based operator
operator-sdk init --plugins=ansible --domain example.com
operator-sdk create api --group apps --version v1alpha1 --kind MyApp --generate-role
# Edit roles/myapp/tasks/main.ymlHelm-based operator:
bash
# Create Helm-based operator
operator-sdk init --plugins=helm --domain example.com --helm-chart=<chart-name>6. Operators の Deploy と Test:
bash
# Deploy operator
make deploy
# Create custom resource
kubectl apply -f config/samples/
# Check operator logs
kubectl logs -f deployment/my-operator-controller-manager -n my-operator-system
# Check resource status
kubectl get myapps
kubectl describe myapp my-app7. Operator Maturity Levels:
operator maturity model は operators の capability levels を定義します。
- Basic Install: Application installation と configuration
- Seamless Upgrades: versions 間の automatic upgrades
- Full Lifecycle: Backup、restore、failure recovery など
- Deep Insights: Auto-scaling、tuning など
- Auto Pilot: monitoring-based automatic optimization
8. Best Practices:
- features を段階的に実装する（simple things から始める）
- 徹底した error handling と logging
- idempotency を確保する（同じ input には同じ result）
- owner references を設定する（resource hierarchy と garbage collection）
- status updates を通じて progress を報告する
- unit tests と integration tests を書く
- 明確な documentation
- Kubernetes における Admission Webhooks の種類と、それぞれの use cases を説明してください。
回答を表示
回答:
Kubernetes Admission Webhooks の種類と Use Cases:
Admission webhooks は、Kubernetes API server が requests を persistent storage (etcd) に保存する前に、それらを intercept して modify または validate できるメカニズムです。Admission webhooks は大きく 2 種類に分かれます: Mutating webhooks と Validating webhooks です。
1. Mutating Webhook:
Mutating webhooks は API server に入ってくる request objects を modify できます。これらの webhooks は validating webhooks より前に実行されます。
Key Characteristics:
- request objects を modify できます
- 複数の mutating webhooks が chain で実行されます
- 各 webhook は前の webhook によって modify された object を受け取ります
Configuration Example:
yaml
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
name: sidecar-injector
webhooks:
- name: sidecar-injector.example.com
clientConfig:
service:
namespace: webhook-system
name: sidecar-injector
path: "/inject"
caBundle: <base64-encoded-ca-cert>
rules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE"]
resources: ["pods"]
scope: "Namespaced"
admissionReviewVersions: ["v1", "v1beta1"]
sideEffects: None
timeoutSeconds: 5Common Use Cases:
Sidecar Container Injection:
- Istio や Linkerd のような service meshes における automatic proxy sidecar injection
- logging と monitoring sidecars の追加
- 例: Istio の sidecar injector は pods が作成されると Envoy proxy containers を自動的に追加します
Setting Defaults:
- automatic resource requests と limits setting
- security context defaults の適用
- labels と annotations の自動追加
- 例: すべての pods に default CPU と memory requests を設定する
Applying Image Policies:
- image registry URLs の変更
- image tags から digests への変換
- 例:
nginx:latestをinternal-registry.example.com/nginx:v1.19.0に変更する
Volume Modifications:
- default volume mounts の追加
- ConfigMap または Secret の自動 mounting
- 例: すべての pods に対する automatic service account token volume mounting
Applying Network Policies:
- default network settings の追加
- DNS configuration の変更
- 例: 特定の namespace 内のすべての pods に特定の DNS settings を適用する
2. Validating Webhook:
Validating webhooks は API server に入ってくる requests を validate し、allow または deny できます。これらの webhooks は mutating webhooks の後に実行されます。
Key Characteristics:
- request objects を modify できません
- requests を allow または deny することだけができます
- 複数の validating webhooks が parallel に実行されます
- request が処理されるには、すべての webhooks が allow する必要があります
Configuration Example:
yaml
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: pod-policy-validator
webhooks:
- name: pod-policy.example.com
clientConfig:
service:
namespace: webhook-system
name: pod-policy-validator
path: "/validate"
caBundle: <base64-encoded-ca-cert>
rules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["pods"]
scope: "Namespaced"
admissionReviewVersions: ["v1", "v1beta1"]
sideEffects: None
timeoutSeconds: 5Common Use Cases:
Enforcing Security Policies:
- privileged containers の禁止
- root user execution の禁止
- host network/PID/IPC usage の制限
- 例: privileged mode で実行される pods を deny する
Validating Resource Constraints:
- resource requests と limits の必須化
- resource caps の適用
- QoS classes の enforcement
- 例: memory limits のない pods を deny する
Validating Image Policies:
- approved registries のみを許可
- latest tag usage の禁止
- vulnerability scan results の検証
- 例: official registries からの images のみを許可する
Validating Labels and Annotations:
- required labels の確認
- label formats の検証
- 例: すべての pods で
appとenvironmentlabels を必須にする
Namespace-Based Policies:
- per-namespace resource limits
- per-namespace feature restrictions
- 例: production namespaces でより厳格な policies を適用する
3. Webhook Implementation Methods:
Admission webhooks は HTTPS endpoints を提供する services として実装されます。これらの services は AdmissionReview requests を受け取り、処理し、AdmissionResponse を返します。
Basic Webhook Server Implementation Example (Go):
go
package main
import (
"encoding/json"
"io/ioutil"
"net/http"
admissionv1 "k8s.io/api/admission/v1"
corev1 "k8s.io/api/core/v1"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/apimachinery/pkg/runtime"
"k8s.io/apimachinery/pkg/runtime/serializer"
)
var (
runtimeScheme = runtime.NewScheme()
codecs = serializer.NewCodecFactory(runtimeScheme)
deserializer = codecs.UniversalDeserializer()
)
// Mutating webhook handler
func mutateHandler(w http.ResponseWriter, r *http.Request) {
body, err := ioutil.ReadAll(r.Body)
if err != nil {
http.Error(w, "Failed to read request body", http.StatusBadRequest)
return
}
// Decode AdmissionReview request
admissionReview := admissionv1.AdmissionReview{}
if _, _, err := deserializer.Decode(body, nil, &admissionReview); err != nil {
http.Error(w, "Failed to decode request", http.StatusBadRequest)
return
}
// Decode pod object
pod := corev1.Pod{}
if err := json.Unmarshal(admissionReview.Request.Object.Raw, &pod); err != nil {
http.Error(w, "Failed to decode pod", http.StatusBadRequest)
return
}
// Create patch (add sidecar container)
patch := []map[string]interface{}{
{
"op": "add",
"path": "/spec/containers/-",
"value": map[string]interface{}{
"name": "sidecar",
"image": "sidecar-image:latest",
"resources": map[string]interface{}{
"limits": map[string]interface{}{
"cpu": "100m",
"memory": "100Mi",
},
"requests": map[string]interface{}{
"cpu": "50m",
"memory": "50Mi",
},
},
},
},
}
// Convert patch to JSON
patchBytes, err := json.Marshal(patch)
if err != nil {
http.Error(w, "Failed to marshal patch", http.StatusInternalServerError)
return
}
// Create response
admissionResponse := admissionv1.AdmissionResponse{
UID: admissionReview.Request.UID,
Allowed: true,
Patch: patchBytes,
PatchType: func() *admissionv1.PatchType {
pt := admissionv1.PatchTypeJSONPatch
return &pt
}(),
}
// Send response
admissionReview.Response = &admissionResponse
resp, err := json.Marshal(admissionReview)
if err != nil {
http.Error(w, "Failed to marshal response", http.StatusInternalServerError)
return
}
w.Header().Set("Content-Type", "application/json")
w.Write(resp)
}
// Validating webhook handler
func validateHandler(w http.ResponseWriter, r *http.Request) {
body, err := ioutil.ReadAll(r.Body)
if err != nil {
http.Error(w, "Failed to read request body", http.StatusBadRequest)
return
}
// Decode AdmissionReview request
admissionReview := admissionv1.AdmissionReview{}
if _, _, err := deserializer.Decode(body, nil, &admissionReview); err != nil {
http.Error(w, "Failed to decode request", http.StatusBadRequest)
return
}
// Decode pod object
pod := corev1.Pod{}
if err := json.Unmarshal(admissionReview.Request.Object.Raw, &pod); err != nil {
http.Error(w, "Failed to decode pod", http.StatusBadRequest)
return
}
// Validation logic
allowed := true
var message string
// Check for privileged containers
for _, container := range pod.Spec.Containers {
if container.SecurityContext != nil && container.SecurityContext.Privileged != nil && *container.SecurityContext.Privileged {
allowed = false
message = "Privileged containers are not allowed"
break
}
}
// Create response
admissionResponse := admissionv1.AdmissionResponse{
UID: admissionReview.Request.UID,
Allowed: allowed,
}
if !allowed {
admissionResponse.Result = &metav1.Status{
Message: message,
Status: "Failure",
Reason: metav1.StatusReasonForbidden,
Code: 403,
}
}
// Send response
admissionReview.Response = &admissionResponse
resp, err := json.Marshal(admissionReview)
if err != nil {
http.Error(w, "Failed to marshal response", http.StatusInternalServerError)
return
}
w.Header().Set("Content-Type", "application/json")
w.Write(resp)
}
func main() {
http.HandleFunc("/mutate", mutateHandler)
http.HandleFunc("/validate", validateHandler)
fmt.Println("Starting webhook server on :8443")
http.ListenAndServeTLS(":8443", "tls.crt", "tls.key", nil)
}4. Webhook Deployment and Configuration:
Webhook servers は通常 Kubernetes cluster 内に deploy され、service と TLS certificates が必要です。
yaml
# Webhook server deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: webhook-server
namespace: webhook-system
spec:
replicas: 1
selector:
matchLabels:
app: webhook-server
template:
metadata:
labels:
app: webhook-server
spec:
containers:
- name: server
image: webhook-server:latest
ports:
- containerPort: 8443
volumeMounts:
- name: tls
mountPath: "/etc/webhook/certs"
readOnly: true
volumes:
- name: tls
secret:
secretName: webhook-server-tls
---
# Webhook server service
apiVersion: v1
kind: Service
metadata:
name: webhook-server
namespace: webhook-system
spec:
selector:
app: webhook-server
ports:
- port: 443
targetPort: 84435. Best Practices:
- Performance Optimization: Webhooks は API server request path 上にあるため、迅速に応答する必要があります。
- Error Handling: webhook server が失敗した場合の behavior を考慮し、
failurePolicyを適切に設定します。 - Scope Limitation: webhooks は必要な resources と operations にのみ適用します。
- Testing: さまざまな scenarios で webhook behavior を徹底的に test します。
- Monitoring: webhook server performance と errors を monitor します。
- Version Management: API version changes に備えて、AdmissionReview の複数 versions をサポートします。
Hands-on Questions
- 次の requirements を満たす CustomResourceDefinition (CRD) を書いてください。
- API Group: webapp.example.com
- Version: v1
- Kind: WebApp
- Scope: Namespaced
- Required fields: spec.image, spec.replicas
- Validation rules: replicas must be an integer between 1 and 10
- Enable status subresource
回答を表示
回答:
yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: webapps.webapp.example.com
spec:
group: webapp.example.com
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
required: ["spec"]
properties:
spec:
type: object
required: ["image", "replicas"]
properties:
image:
type: string
replicas:
type: integer
minimum: 1
maximum: 10
port:
type: integer
default: 80
env:
type: array
items:
type: object
required: ["name"]
properties:
name:
type: string
value:
type: string
status:
type: object
properties:
availableReplicas:
type: integer
phase:
type: string
subresources:
status: {}
additionalPrinterColumns:
- name: Replicas
type: integer
jsonPath: .spec.replicas
- name: Image
type: string
jsonPath: .spec.image
- name: Age
type: date
jsonPath: .metadata.creationTimestamp
scope: Namespaced
names:
plural: webapps
singular: webapp
kind: WebApp
shortNames:
- waこの CRD には次の特徴があります。
Basic Information:
- API Group:
webapp.example.com - Version:
v1 - Kind:
WebApp - Scope:
Namespaced
- API Group:
Schema Validation:
specfield は必須です。spec.imageとspec.replicasは required fields です。spec.replicasは 1 から 10 の間の integer である必要があります。spec.portは default value 80 を持つ optional field です。spec.envは environment variables の array を定義する optional field です。
Status Subresource:
statussubresource が有効化され、controllers が status を update できます。status.availableReplicasとstatus.phasefields が定義されています。
Additional Printer Columns:
kubectl get webappsを実行すると、Replicas、Image、Age columns が表示されます。
Name Configuration:
- Plural:
webapps - Singular:
webapp - Kind:
WebApp - Short name:
wa
- Plural:
この CRD を使用すると、次のような custom resources を作成できます。
yaml
apiVersion: webapp.example.com/v1
kind: WebApp
metadata:
name: my-webapp
namespace: default
spec:
image: nginx:1.19
replicas: 3
port: 8080
env:
- name: ENV_VAR1
value: "value1"
- name: ENV_VAR2
value: "value2"Controllers はこの resource を watch して status を update できます。
yaml
status:
availableReplicas: 3
phase: Running- 次の requirements を満たす Mutating Admission Webhook configuration を書いてください。
- Add sidecar container to all pod creation requests
- Apply only to a specific namespace (monitoring)
- Webhook service: webhook-service.webhook-system.svc
- Path: /mutate
回答を表示
回答:
yaml
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
name: sidecar-injector
webhooks:
- name: sidecar-injector.example.com
clientConfig:
service:
namespace: webhook-system
name: webhook-service
path: "/mutate"
caBundle: ${CA_BUNDLE} # Replace with base64-encoded CA certificate in actual environment
rules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE"]
resources: ["pods"]
scope: "Namespaced"
namespaceSelector:
matchLabels:
monitoring-injection: enabled
admissionReviewVersions: ["v1", "v1beta1"]
sideEffects: None
timeoutSeconds: 5
failurePolicy: Fail
---
# Add label to namespace
apiVersion: v1
kind: Namespace
metadata:
name: monitoring
labels:
monitoring-injection: enabledこの configuration には次の特徴があります。
Webhook Configuration:
- Name:
sidecar-injector - Webhook service:
webhook-service.webhook-system.svc - Path:
/mutate
- Name:
Scope:
- API Group:
""(core API group) - API Version:
v1 - Operation:
CREATE(pod creation 時のみ適用) - Resource:
pods - Scope:
Namespaced
- API Group:
Namespace Selector:
monitoring-injection: enabledlabel を持つ namespaces にのみ適用- この label を
monitoringnamespace に追加します
Additional Settings:
admissionReviewVersions: サポートされる AdmissionReview API versionssideEffects: webhook による side effects はありませんtimeoutSeconds: webhook response wait timefailurePolicy: webhook failure 時に requests を deny
webhook server は次のような logic を実装する必要があります。
go
func mutateHandler(w http.ResponseWriter, r *http.Request) {
// Decode request
body, _ := ioutil.ReadAll(r.Body)
admissionReview := admissionv1.AdmissionReview{}
deserializer.Decode(body, nil, &admissionReview)
// Decode pod object
pod := corev1.Pod{}
json.Unmarshal(admissionReview.Request.Object.Raw, &pod)
// Define sidecar container
sidecarContainer := corev1.Container{
Name: "monitoring-sidecar",
Image: "monitoring-agent:latest",
Resources: corev1.ResourceRequirements{
Limits: corev1.ResourceList{
corev1.ResourceCPU: resource.MustParse("100m"),
corev1.ResourceMemory: resource.MustParse("100Mi"),
},
Requests: corev1.ResourceList{
corev1.ResourceCPU: resource.MustParse("50m"),
corev1.ResourceMemory: resource.MustParse("50Mi"),
},
},
VolumeMounts: []corev1.VolumeMount{
{
Name: "shared-data",
MountPath: "/var/monitoring",
},
},
}
// Create patch
patch := []map[string]interface{}{
{
"op": "add",
"path": "/spec/containers/-",
"value": sidecarContainer,
},
{
"op": "add",
"path": "/spec/volumes/-",
"value": map[string]interface{}{
"name": "shared-data",
"emptyDir": map[string]interface{}{},
},
},
}
// Convert patch to JSON
patchBytes, _ := json.Marshal(patch)
// Create response
admissionResponse := admissionv1.AdmissionResponse{
UID: admissionReview.Request.UID,
Allowed: true,
Patch: patchBytes,
PatchType: func() *admissionv1.PatchType {
pt := admissionv1.PatchTypeJSONPatch
return &pt
}(),
}
// Send response
admissionReview.Response = &admissionResponse
resp, _ := json.Marshal(admissionReview)
w.Header().Set("Content-Type", "application/json")
w.Write(resp)
}この webhook は monitoring namespace で作成されるすべての pods に monitoring sidecar container を自動的に追加します。sidecar container は monitoring agent image を使用し、main container と data を共有するために shared volume を mount します。