Kubernetes & Amazon EKS Training

日本語

한국어
English
中文
Español

日本語

한국어
English
中文
Español

Appearance

Extending Kubernetes ​

Supported Versions: Kubernetes 1.32, 1.33, 1.34 最終更新: February 19, 2026

Kubernetes は extensibility を念頭に置いて設計された platform であり、さまざまな方法で機能を拡張できます。この章では、Kubernetes を拡張するためのさまざまな方法と、Amazon EKS で extension features を活用する方法を見ていきます。

Table of Contents ​

  1. Kubernetes Extension Overview
  2. Custom Resources
  3. Operator Pattern
  4. Admission Controllers
  5. API Server Extensions
  6. Scheduler Extensions
  7. Cloud Controller Manager
  8. CSI (Container Storage Interface)
  9. CNI (Container Network Interface)
  10. Device Plugins
  11. Extension Features in Amazon EKS
  12. Best Practices
  13. Conclusion

Kubernetes Extension Overview ​

Kubernetes は、基本機能を拡張および customize するためのさまざまな extension points を提供します。主な extension points は次のとおりです。

  1. Custom Resources: 新しい API object types を定義します
  2. Operators: custom resources と controllers を組み合わせて複雑な applications を管理します
  3. Admission Controllers: API requests を intercept、modify、または validate します
  4. API Server Extensions: API server に新しい endpoints を追加します
  5. Scheduler Extensions: Pod scheduling logic を customize します
  6. Cloud Controller Manager: cloud provider-specific features を統合します
  7. CSI (Container Storage Interface): storage systems を統合します
  8. CNI (Container Network Interface): networking solutions を統合します
  9. Device Plugins: special hardware を統合します

次の diagram は、Kubernetes の主な extension points を示しています。

Choosing an Extension Method ​

適切な extension method を選択する際の考慮事項は次のとおりです。

  1. Use Case: 拡張したい機能の種類
  2. Complexity: 実装と maintenance の複雑さ
  3. Performance Impact: extension が cluster performance に与える影響
  4. Upgrade Compatibility: Kubernetes version upgrades との互換性
  5. Community Support: その extension method に対する community support の水準

Custom Resources ​

Custom resources は、Kubernetes API を拡張して新しい object types を定義する方法です。

次の diagram は、custom resources がどのように機能するかを示しています。

Custom Resource Definitions (CRD) ​

CRD は、新しい resource types を定義する最も簡単な方法です。

yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: backups.example.com
spec:
  group: example.com
  names:
    kind: Backup
    listKind: BackupList
    plural: backups
    singular: backup
    shortNames:
    - bk
  scope: Namespaced
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              source:
                type: string
              destination:
                type: string
              schedule:
                type: string
            required:
            - source
            - destination
          status:
            type: object
            properties:
              phase:
                type: string
              lastBackupTime:
                type: string
                format: date-time
    subresources:
      status: {}
    additionalPrinterColumns:
    - name: Status
      type: string
      jsonPath: .status.phase
    - name: Age
      type: date
      jsonPath: .metadata.creationTimestamp

上記の例では、Backup という新しい resource type を定義し、その resource の schema と additional printer columns を指定しています。

Creating Custom Resource Instances ​

CRD を定義した後、その type の resource instances を作成できます。

yaml
apiVersion: example.com/v1
kind: Backup
metadata:
  name: daily-backup
spec:
  source: /data
  destination: s3://my-bucket/backups
  schedule: "0 0 * * *"

Custom Resource Validation ​

CRD の OpenAPI v3 schemas を使用して custom resources を validate できます。

yaml
openAPIV3Schema:
  type: object
  properties:
    spec:
      type: object
      properties:
        replicas:
          type: integer
          minimum: 1
          maximum: 10
        image:
          type: string
          pattern: '^[a-zA-Z0-9./:_-]+$'
      required:
      - replicas
      - image

上記の例では、replicas field は 1 から 10 までの integer である必要があり、image field は指定された pattern に一致する必要があります。

Version Management ​

CRD は API evolution を可能にするため、複数の versions を support します。

yaml
versions:
- name: v1alpha1
  served: true
  storage: false
- name: v1beta1
  served: true
  storage: false
- name: v1
  served: true
  storage: true

上記の例では、v1alpha1、v1beta1、v1 の 3 つの versions が served されますが、data は v1 format で保存されます。

Conversion Webhooks ​

Conversion webhooks を使用して、異なる versions 間の conversions を処理できます。

yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: backups.example.com
spec:
  # ... other fields omitted ...
  conversion:
    strategy: Webhook
    webhook:
      clientConfig:
        service:
          namespace: default
          name: example-conversion-webhook
          path: /convert
      conversionReviewVersions:
      - v1

Operator Pattern ​

Operator pattern は、custom resources と controllers を組み合わせることで、複雑な applications の operational knowledge を automate する方法です。

次の diagram は、operator pattern がどのように機能するかを示しています。

Operator Concepts ​

Operator は次の components で構成されます。

  1. Custom Resource Definition (CRD): 管理する resources の schema を定義します
  2. Controller: custom resources を monitor し、それらを desired state に reconcile する logic
  3. Kubernetes API Client: Kubernetes API とやり取りするための client

Operator Example ​

Database operator の例:

yaml
# Custom Resource Definition
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: databases.example.com
spec:
  group: example.com
  names:
    kind: Database
    listKind: DatabaseList
    plural: databases
    singular: database
    shortNames:
    - db
  scope: Namespaced
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              engine:
                type: string
                enum:
                - mysql
                - postgresql
              version:
                type: string
              storageSize:
                type: string
              replicas:
                type: integer
                minimum: 1
            required:
            - engine
            - version
            - storageSize
          status:
            type: object
            properties:
              phase:
                type: string
              endpoint:
                type: string
    subresources:
      status: {}
yaml
# Database Instance
apiVersion: example.com/v1
kind: Database
metadata:
  name: my-db
spec:
  engine: postgresql
  version: "13.4"
  storageSize: 10Gi
  replicas: 3

Operator Development Tools ​

Operator を開発するための tools:

  1. Operator SDK: Go、Ansible、または Helm を使用して operators を開発します
  2. KUDO (Kubernetes Universal Declarative Operator): operators を declaratively に開発します
  3. Kubebuilder: Go-based operator development framework
  4. Metacontroller: Webhook-based operator development

Operator SDK Example ​

Operator SDK を使用した operator の作成:

bash
# Install Operator SDK
curl -LO https://github.com/operator-framework/operator-sdk/releases/download/v1.16.0/operator-sdk_linux_amd64
chmod +x operator-sdk_linux_amd64
mv operator-sdk_linux_amd64 /usr/local/bin/operator-sdk

# Create new operator project
operator-sdk init --domain example.com --repo github.com/example/database-operator

# Create API
operator-sdk create api --group database --version v1 --kind Database --resource --controller

# Implement controller (main.go, controllers/database_controller.go, etc.)

# Build and deploy operator
make docker-build docker-push
make deploy

人気のある open source operators:

  1. Prometheus Operator: Prometheus monitoring stack を管理します
  2. Elasticsearch Operator: Elasticsearch clusters を管理します
  3. etcd Operator: etcd clusters を管理します
  4. PostgreSQL Operator: PostgreSQL databases を管理します
  5. Jaeger Operator: Jaeger distributed tracing system を管理します
  6. Strimzi Kafka Operator: Apache Kafka clusters を管理します
  7. Istio Operator: Istio service mesh を管理します

Admission Controllers ​

Admission controllers は、Kubernetes API server への requests を intercept し、modify または validate する plugins です。

次の diagram は、admission controllers がどのように機能するかを示しています。

Admission Controller Types ​

Kubernetes には 2 種類の admission controllers があります。

  1. Mutating Admission Controllers: resources を modify できます
  2. Validating Admission Controllers: resources の validate のみ可能です

Built-in Admission Controllers ​

Kubernetes には、いくつかの built-in admission controllers があります。

  1. NamespaceLifecycle: 削除中の namespaces で resource creation を防ぎます
  2. LimitRanger: pods と containers に default resource limits を設定します
  3. ServiceAccount: service accounts を自動作成し、tokens を追加します
  4. DefaultStorageClass: PVCs に default storage class を割り当てます
  5. ResourceQuota: namespace ごとの resource usage を制限します
  6. PodSecurityPolicy: pod security policies を適用します
  7. NodeRestriction: nodes が modify できる resources を制限します

Webhook Admission Controllers ​

Webhook admission controllers を使用して custom logic を実装できます。

yaml
# Mutating Webhook Configuration
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: pod-mutating-webhook
webhooks:
- name: pod-mutator.example.com
  clientConfig:
    service:
      namespace: default
      name: pod-mutating-webhook
      path: "/mutate"
    caBundle: <base64-encoded-ca-cert>
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations: ["CREATE"]
    scope: "Namespaced"
  admissionReviewVersions: ["v1", "v1beta1"]
  sideEffects: None
  timeoutSeconds: 5
yaml
# Validating Webhook Configuration
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: pod-validating-webhook
webhooks:
- name: pod-validator.example.com
  clientConfig:
    service:
      namespace: default
      name: pod-validating-webhook
      path: "/validate"
    caBundle: <base64-encoded-ca-cert>
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations: ["CREATE", "UPDATE"]
    scope: "Namespaced"
  admissionReviewVersions: ["v1", "v1beta1"]
  sideEffects: None
  timeoutSeconds: 5

Webhook Server Implementation ​

Webhook server は次のような endpoints を実装する必要があります。

go
// Mutating webhook example
func mutateHandler(w http.ResponseWriter, r *http.Request) {
    var body []byte
    if r.Body != nil {
        if data, err := ioutil.ReadAll(r.Body); err == nil {
            body = data
        }
    }

    // Convert to AdmissionReview object
    admissionReview := v1.AdmissionReview{}
    if err := json.Unmarshal(body, &admissionReview); err != nil {
        http.Error(w, "Could not parse admission review request", http.StatusBadRequest)
        return
    }

    // Extract Pod object
    pod := corev1.Pod{}
    if err := json.Unmarshal(admissionReview.Request.Object.Raw, &pod); err != nil {
        http.Error(w, "Could not parse pod object", http.StatusBadRequest)
        return
    }

    // Create patch
    patches := []map[string]interface{}{
        {
            "op":    "add",
            "path":  "/metadata/labels/injected-by",
            "value": "mutating-webhook",
        },
    }

    patchBytes, _ := json.Marshal(patches)

    // Create response
    admissionResponse := v1.AdmissionResponse{
        UID:     admissionReview.Request.UID,
        Allowed: true,
        Patch:   patchBytes,
        PatchType: func() *v1.PatchType {
            pt := v1.PatchTypeJSONPatch
            return &pt
        }(),
    }

    admissionReview.Response = &admissionResponse
    resp, _ := json.Marshal(admissionReview)
    w.Header().Set("Content-Type", "application/json")
    w.Write(resp)
}
go
// Validating webhook example
func validateHandler(w http.ResponseWriter, r *http.Request) {
    var body []byte
    if r.Body != nil {
        if data, err := ioutil.ReadAll(r.Body); err == nil {
            body = data
        }
    }

    // Convert to AdmissionReview object
    admissionReview := v1.AdmissionReview{}
    if err := json.Unmarshal(body, &admissionReview); err != nil {
        http.Error(w, "Could not parse admission review request", http.StatusBadRequest)
        return
    }

    // Extract Pod object
    pod := corev1.Pod{}
    if err := json.Unmarshal(admissionReview.Request.Object.Raw, &pod); err != nil {
        http.Error(w, "Could not parse pod object", http.StatusBadRequest)
        return
    }

    // Validation logic
    allowed := true
    var message string
    for _, container := range pod.Spec.Containers {
        if container.Image == "nginx:latest" {
            allowed = false
            message = "Using 'latest' tag is not allowed. Please specify a version."
            break
        }
    }

    // Create response
    admissionResponse := v1.AdmissionResponse{
        UID:     admissionReview.Request.UID,
        Allowed: allowed,
    }

    if !allowed {
        admissionResponse.Result = &metav1.Status{
            Message: message,
        }
    }

    admissionReview.Response = &admissionResponse
    resp, _ := json.Marshal(admissionReview)
    w.Header().Set("Content-Type", "application/json")
    w.Write(resp)
}
  1. OPA Gatekeeper: Open Policy Agent を使用した policy enforcement
  2. Kyverno: YAML-based policy engine
  3. Istio: Service mesh sidecar injection
  4. cert-manager: TLS certificate management

API Server Extensions ​

API server extensions は、Kubernetes API server に新しい endpoints を追加する方法です。

Extension API Servers ​

Extension API servers は、Kubernetes API server とは別に実行され、custom APIs を提供する servers です。

yaml
# APIService Definition
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1.example.com
spec:
  group: example.com
  version: v1
  groupPriorityMinimum: 1000
  versionPriority: 15
  service:
    name: example-api
    namespace: default
  caBundle: <base64-encoded-ca-cert>

Extension API Server Implementation ​

Extension API server は次の components で構成されます。

  1. API Server: Kubernetes API server と類似した interface を提供します
  2. Resource Handlers: 特定の resource types に対する requests を処理します
  3. Storage Backend: resource data を保存します
go
// Extension API Server Example
func main() {
    // Server configuration
    config := genericapiserver.NewRecommendedConfig(apiserver.Codecs)
    config.OpenAPIConfig = genericapiserver.DefaultOpenAPIConfig(
        sampleopenapi.GetOpenAPIDefinitions,
        openapi.NewDefinitionNamer(apiserver.Scheme),
    )
    config.EnableIndex = true
    config.EnableDiscovery = true

    // Create server
    server, err := config.Complete().New("sample-apiserver", genericapiserver.NewEmptyDelegate())
    if err != nil {
        log.Fatalf("Error creating server: %v", err)
    }

    // Set API group info
    apiGroupInfo := genericapiserver.NewDefaultAPIGroupInfo(
        samplev1alpha1.GroupName,
        apiserver.Scheme,
        metav1.ParameterCodec,
        apiserver.Codecs,
    )

    // Set storage
    apiGroupInfo.VersionedResourcesStorageMap["v1alpha1"] = map[string]rest.Storage{
        "widgets": NewWidgetStorage(),
    }

    // Install API group
    if err := server.InstallAPIGroup(&apiGroupInfo); err != nil {
        log.Fatalf("Error installing API group: %v", err)
    }

    // Run server
    if err := server.PrepareRun().Run(stopCh); err != nil {
        log.Fatalf("Error running server: %v", err)
    }
}

Aggregation Layer ​

Aggregation layer は、複数の API servers を 1 つの API server のように見せます。

                                   +-----------------+
                                   |                 |
                                   |  kube-apiserver |
                                   |                 |
                                   +-------+---------+
                                           |
                                           v
                      +--------------------+--------------------+
                      |                                         |
                      |                                         |
          +-----------v-----------+               +------------v------------+
          |                       |               |                         |
          |  metrics-server       |               |  example-apiserver      |
          |                       |               |                         |
          +-----------------------+               +-------------------------+

Scheduler Extensions ​

Scheduler extensions は、Kubernetes scheduler の behavior を customize する方法です。

Scheduler Framework ​

Kubernetes 1.15 で導入された scheduler framework により、plugins を通じて scheduling pipeline のさまざまな stages を拡張できます。

  1. Queue Sort: scheduling queue 内の pods を sort します
  2. Pre-filter: filtering の前に pod と cluster state を確認します
  3. Filter: pod を実行できない nodes を filter out します
  4. Post-filter: filtering 後に actions を実行します
  5. Pre-score: score calculation の前に actions を実行します
  6. Score: nodes に scores を割り当てます
  7. Normalize Score: scores を normalize します
  8. Reserve: pod の resources を reserve します
  9. Permit: pod scheduling を allow、deny、または delay します
  10. Pre-bind: binding の前に actions を実行します
  11. Bind: pod を node に bind します
  12. Post-bind: binding 後に actions を実行します

Scheduler Configuration ​

Scheduler configuration の例:

yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
leaderElection:
  leaderElect: true
clientConnection:
  kubeconfig: /etc/kubernetes/scheduler.conf
profiles:
- schedulerName: default-scheduler
  plugins:
    queueSort:
      enabled:
      - name: PrioritySort
    preFilter:
      enabled:
      - name: NodeResourcesFit
      - name: NodePorts
      - name: PodTopologySpread
      - name: InterPodAffinity
      - name: VolumeBinding
      - name: NodeAffinity
    filter:
      enabled:
      - name: NodeUnschedulable
      - name: NodeName
      - name: TaintToleration
      - name: NodeAffinity
      - name: NodePorts
      - name: NodeResourcesFit
      - name: VolumeRestrictions
      - name: EBSLimits
      - name: GCEPDLimits
      - name: NodeVolumeLimits
      - name: AzureDiskLimits
      - name: VolumeBinding
      - name: VolumeZone
      - name: PodTopologySpread
      - name: InterPodAffinity
    postFilter:
      enabled:
      - name: DefaultPreemption
    preScore:
      enabled:
      - name: InterPodAffinity
      - name: PodTopologySpread
      - name: TaintToleration
      - name: NodeAffinity
    score:
      enabled:
      - name: NodeResourcesBalancedAllocation
        weight: 1
      - name: ImageLocality
        weight: 1
      - name: InterPodAffinity
        weight: 1
      - name: NodeResourcesFit
        weight: 1
      - name: NodeAffinity
        weight: 1
      - name: PodTopologySpread
        weight: 2
      - name: TaintToleration
        weight: 1
    reserve:
      enabled:
      - name: VolumeBinding
    permit:
      enabled: []
    preBind:
      enabled:
      - name: VolumeBinding
    bind:
      enabled:
      - name: DefaultBinder
    postBind:
      enabled: []

Custom Scheduler ​

Kubernetes と並行して実行する独自の scheduler を実装することもできます。

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-scheduler
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: custom-scheduler
  template:
    metadata:
      labels:
        app: custom-scheduler
    spec:
      serviceAccountName: custom-scheduler
      containers:
      - name: custom-scheduler
        image: example/custom-scheduler:v1.0.0
        command:
        - /custom-scheduler
        - --kubeconfig=/etc/kubernetes/scheduler.conf
        volumeMounts:
        - name: kubeconfig
          mountPath: /etc/kubernetes/scheduler.conf
          readOnly: true
      volumes:
      - name: kubeconfig
        hostPath:
          path: /etc/kubernetes/scheduler.conf
          type: File

Pod に custom scheduler を指定する例:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: custom-scheduled-pod
spec:
  schedulerName: custom-scheduler
  containers:
  - name: container
    image: nginx

Cloud Controller Manager ​

Cloud controller manager は、Kubernetes と cloud providers の間の interface を提供します。

Cloud Controller Manager Components ​

Cloud controller manager は次の controllers で構成されます。

  1. Node Controller: cloud provider APIs を通じて node information を更新します
  2. Route Controller: cloud networks に routes を設定します
  3. Service Controller: cloud load balancers を作成、更新、削除します

AWS Cloud Controller Manager ​

AWS Cloud Controller Manager configuration の例:

yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-cloud-controller-manager
  namespace: kube-system
data:
  cloud.conf: |
    [global]
    zone = us-east-1a
    vpc = vpc-xxx
    subnet-id = subnet-xxx
    role-arn = arn:aws:iam::xxx:role/xxx
    kubernetes.io/cluster/my-cluster = owned
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: aws-cloud-controller-manager
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: aws-cloud-controller-manager
  template:
    metadata:
      labels:
        k8s-app: aws-cloud-controller-manager
    spec:
      nodeSelector:
        node-role.kubernetes.io/master: ""
      tolerations:
      - key: node.cloudprovider.kubernetes.io/uninitialized
        value: "true"
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      serviceAccountName: cloud-controller-manager
      containers:
      - name: aws-cloud-controller-manager
        image: k8s.gcr.io/cloud-controller-manager:v1.21.0
        command:
        - /usr/local/bin/cloud-controller-manager
        - --cloud-provider=aws
        - --cloud-config=/etc/kubernetes/cloud.conf
        - --use-service-account-credentials
        - --allocate-node-cidrs=false
        volumeMounts:
        - name: cloud-config
          mountPath: /etc/kubernetes/cloud.conf
          readOnly: true
      volumes:
      - name: cloud-config
        configMap:
          name: aws-cloud-controller-manager

CSI (Container Storage Interface) ​

CSI は、Kubernetes と storage systems の間の standard interface を提供します。

次の diagram は、CSI の architecture と operation を示しています。

CSI Architecture ​

CSI は次の components で構成されます。

  1. CSI Controller Plugin: volume creation、deletion、snapshots などを処理します
  2. CSI Node Plugin: volume mount、unmount などを処理します
  3. CSI Driver: 特定の storage systems と統合する implementation
+-------------------+
|                   |
|  Kubernetes       |
|  (External        |
|   Provisioner)    |
|                   |
+--------+----------+
         |
         | gRPC
         v
+--------+----------+
|                   |
|  CSI Driver       |
|                   |
+--------+----------+
         |
         | Storage Protocol
         v
+--------+----------+
|                   |
|  Storage System   |
|                   |
+-------------------+

CSI Driver Deployment ​

CSI driver deployment の例:

yaml
# CSI Controller Service
apiVersion: apps/v1
kind: Deployment
metadata:
  name: csi-controller
spec:
  replicas: 1
  selector:
    matchLabels:
      app: csi-controller
  template:
    metadata:
      labels:
        app: csi-controller
    spec:
      serviceAccountName: csi-controller
      containers:
      - name: csi-provisioner
        image: k8s.gcr.io/sig-storage/csi-provisioner:v2.1.0
        args:
        - "--csi-address=$(ADDRESS)"
        - "--v=5"
        env:
        - name: ADDRESS
          value: /var/lib/csi/sockets/pluginproxy/csi.sock
        volumeMounts:
        - name: socket-dir
          mountPath: /var/lib/csi/sockets/pluginproxy/
      - name: csi-attacher
        image: k8s.gcr.io/sig-storage/csi-attacher:v3.1.0
        args:
        - "--csi-address=$(ADDRESS)"
        - "--v=5"
        env:
        - name: ADDRESS
          value: /var/lib/csi/sockets/pluginproxy/csi.sock
        volumeMounts:
        - name: socket-dir
          mountPath: /var/lib/csi/sockets/pluginproxy/
      - name: csi-driver
        image: example/csi-driver:v1.0.0
        args:
        - "--endpoint=$(CSI_ENDPOINT)"
        - "--nodeid=$(NODE_ID)"
        env:
        - name: CSI_ENDPOINT
          value: unix:///var/lib/csi/sockets/pluginproxy/csi.sock
        - name: NODE_ID
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        volumeMounts:
        - name: socket-dir
          mountPath: /var/lib/csi/sockets/pluginproxy/
      volumes:
      - name: socket-dir
        emptyDir: {}

# CSI Node Service
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: csi-node
spec:
  selector:
    matchLabels:
      app: csi-node
  template:
    metadata:
      labels:
        app: csi-node
    spec:
      serviceAccountName: csi-node
      hostNetwork: true
      containers:
      - name: csi-node-driver-registrar
        image: k8s.gcr.io/sig-storage/csi-node-driver-registrar:v2.1.0
        args:
        - "--csi-address=$(ADDRESS)"
        - "--kubelet-registration-path=$(DRIVER_REG_SOCK_PATH)"
        - "--v=5"
        env:
        - name: ADDRESS
          value: /csi/csi.sock
        - name: DRIVER_REG_SOCK_PATH
          value: /var/lib/kubelet/plugins/example.csi.k8s.io/csi.sock
        volumeMounts:
        - name: plugin-dir
          mountPath: /csi
        - name: registration-dir
          mountPath: /registration
      - name: csi-driver
        image: example/csi-driver:v1.0.0
        args:
        - "--endpoint=$(CSI_ENDPOINT)"
        - "--nodeid=$(NODE_ID)"
        env:
        - name: CSI_ENDPOINT
          value: unix:///csi/csi.sock
        - name: NODE_ID
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        securityContext:
          privileged: true
        volumeMounts:
        - name: plugin-dir
          mountPath: /csi
        - name: pods-mount-dir
          mountPath: /var/lib/kubelet/pods
          mountPropagation: "Bidirectional"
      volumes:
      - name: plugin-dir
        hostPath:
          path: /var/lib/kubelet/plugins/example.csi.k8s.io
          type: DirectoryOrCreate
      - name: registration-dir
        hostPath:
          path: /var/lib/kubelet/plugins_registry
          type: Directory
      - name: pods-mount-dir
        hostPath:
          path: /var/lib/kubelet/pods
          type: Directory

Storage Class and PVC ​

CSI driver を使用した Storage class と PVC の例:

yaml
# Storage Class
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: example-csi
provisioner: example.csi.k8s.io
parameters:
  type: ssd
  fsType: ext4
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

# PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: example-csi
  1. AWS EBS CSI Driver: AWS EBS volume management
  2. AWS EFS CSI Driver: AWS EFS file system management
  3. GCE PD CSI Driver: Google Compute Engine persistent disk management
  4. Azure Disk CSI Driver: Azure disk management
  5. Ceph RBD CSI Driver: Ceph RBD volume management
  6. NFS CSI Driver: NFS volume management

CNI (Container Network Interface) ​

CNI は、Kubernetes と networking solutions の間の standard interface を提供します。

次の diagram は、CNI の architecture と operation を示しています。

CNI Architecture ​

CNI は次の components で構成されます。

  1. CNI Plugin: container network interfaces を configure します
  2. IPAM Plugin: IP address allocation と management
  3. Meta Plugin: 複数の plugins を組み合わせます
+-------------------+
|                   |
|  Kubernetes       |
|  (kubelet)        |
|                   |
+--------+----------+
         |
         | CNI Spec
         v
+--------+----------+
|                   |
|  CNI Plugin       |
|                   |
+--------+----------+
         |
         | Network Configuration
         v
+--------+----------+
|                   |
|  Network          |
|                   |
+-------------------+

CNI Plugin Configuration ​

CNI plugin configuration の例:

json
{
  "cniVersion": "0.4.0",
  "name": "example-network",
  "type": "bridge",
  "bridge": "cni0",
  "isGateway": true,
  "ipMasq": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24",
    "routes": [
      { "dst": "0.0.0.0/0" }
    ]
  }
}
  1. Calico: enhanced network policy と security features を備えた CNI
  2. Flannel: simple overlay networking を提供します
  3. Cilium: eBPF-based networking and security solution
  4. Weave Net: Multi-host container networking solution
  5. AWS VPC CNI: AWS VPC と統合された CNI
  6. Azure CNI: Azure virtual networks と統合された CNI
  7. Antrea: Open vSwitch-based networking solution

CNI Plugin Installation ​

Calico CNI plugin installation の例:

bash
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Device Plugins ​

Device plugins は、Kubernetes と special hardware の間の interface を提供します。

Device Plugin Architecture ​

Device plugins は次の components で構成されます。

  1. Device Plugin Server: device discovery、allocation、initialization などを処理します
  2. kubelet: device plugins と通信して devices を pods に割り当てます
+-------------------+
|                   |
|  Kubernetes       |
|  (kubelet)        |
|                   |
+--------+----------+
         |
         | Device Plugin API
         v
+--------+----------+
|                   |
|  Device Plugin    |
|                   |
+--------+----------+
         |
         | Device Management
         v
+--------+----------+
|                   |
|  Hardware Device  |
|                   |
+-------------------+

NVIDIA GPU Device Plugin ​

NVIDIA GPU device plugin deployment の例:

yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nvidia-device-plugin-daemonset
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: nvidia-device-plugin-ds
  template:
    metadata:
      labels:
        name: nvidia-device-plugin-ds
    spec:
      tolerations:
      - key: nvidia.com/gpu
        operator: Exists
        effect: NoSchedule
      containers:
      - name: nvidia-device-plugin-ctr
        image: nvidia/k8s-device-plugin:v0.9.0
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
        volumeMounts:
        - name: device-plugin
          mountPath: /var/lib/kubelet/device-plugins
      volumes:
      - name: device-plugin
        hostPath:
          path: /var/lib/kubelet/device-plugins

GPU Request Pod ​

GPU を request する Pod の例:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  containers:
  - name: cuda-container
    image: nvidia/cuda:11.0-base
    command: ["nvidia-smi"]
    resources:
      limits:
        nvidia.com/gpu: 1
  1. NVIDIA GPU Device Plugin: NVIDIA GPU management
  2. AMD GPU Device Plugin: AMD GPU management
  3. FPGA Device Plugin: FPGA device management
  4. InfiniBand Device Plugin: InfiniBand device management
  5. SR-IOV Network Device Plugin: SR-IOV network device management

Extension Features in Amazon EKS ​

Amazon EKS は、Kubernetes cluster functionality を拡張するためのさまざまな extension features を support しています。

次の diagram は、Amazon EKS における extension feature architecture を示しています。

EKS Add-ons ​

Amazon EKS は次の add-ons を提供します。

  1. Amazon VPC CNI: AWS VPC と統合された networking
  2. CoreDNS: cluster 内の DNS service
  3. kube-proxy: Network proxy
  4. Amazon EBS CSI Driver: EBS volume management
  5. AWS Load Balancer Controller: AWS load balancer management
bash
# List EKS add-ons
aws eks list-addons --cluster-name my-cluster

# Install EKS add-on
aws eks create-addon \
  --cluster-name my-cluster \
  --addon-name amazon-ebs-csi-driver \
  --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKS_EBS_CSI_DriverRole

# Update EKS add-on
aws eks update-addon \
  --cluster-name my-cluster \
  --addon-name amazon-ebs-csi-driver \
  --addon-version v1.5.0-eksbuild.1

# Delete EKS add-on
aws eks delete-addon \
  --cluster-name my-cluster \
  --addon-name amazon-ebs-csi-driver

AWS Controllers for Kubernetes (ACK) ​

ACK は、Kubernetes から AWS resources を管理できるようにする operators の collection です。

bash
# Install ACK controller
helm repo add ack-controller https://aws.github.io/aws-controllers-k8s
helm install ack-s3-controller ack-controller/s3-chart

# Create S3 bucket
cat <<EOF | kubectl apply -f -
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: my-bucket
spec:
  name: my-bucket-123456
EOF

AWS Load Balancer Controller ​

AWS Load Balancer Controller は、Kubernetes services と ingresses を AWS load balancers と統合します。

yaml
# ALB Ingress example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

IAM Roles for Service Accounts (IRSA) ​

IRSA は、AWS IAM roles を Kubernetes service accounts と関連付けることで、pods が AWS services に安全に access できるようにします。

bash
# Create OIDC provider
eksctl utils associate-iam-oidc-provider \
  --cluster my-cluster \
  --approve

# Create IAM role and service account
eksctl create iamserviceaccount \
  --cluster my-cluster \
  --namespace default \
  --name my-service-account \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --approve

# Pod using service account
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: s3-reader
spec:
  serviceAccountName: my-service-account
  containers:
  - name: aws-cli
    image: amazon/aws-cli:latest
    command:
    - sleep
    - "3600"
EOF

Best Practices ​

Kubernetes extension features を実装する際に考慮すべき best practices を見ていきましょう。

Design Best Practices ​

  1. Use Standard Interfaces: 可能な場合は CSI、CNI などの standard interfaces を使用します
  2. Declarative API Design: imperative ではなく declarative APIs を設計します
  3. Follow Kubernetes Design Principles: controller pattern、level-triggering などの principles に従います
  4. Version Management: API versions を管理し、互換性を維持します
  5. Least Privilege Principle: 必要最小限の permissions のみを付与します

Implementation Best Practices ​

  1. Leverage Reusable Libraries: client-go、controller-runtime などの libraries を活用します
  2. Proper Error Handling: error situations に対して適切な handling と logging を行います
  3. Exponential Backoff: retries には exponential backoff を使用します
  4. Set Resource Limits: memory と CPU limits を設定します
  5. Status Reporting: resource status を正確に report します

Deployment Best Practices ​

  1. Gradual Rollout: すべてを一度に変更するのではなく、段階的に roll out します
  2. Version Management: images に latest tag を使用することを避けます
  3. Health Checks: 適切な liveness probes と readiness probes を configure します
  4. Logging and Monitoring: 包括的な logging と monitoring を configure します
  5. Documentation: APIs と usage を document します

Security Best Practices ​

  1. Least Privilege Principle: 必要最小限の permissions のみを付与します
  2. Use RBAC: 適切な RBAC policies を configure します
  3. Network Policies: 適切な network policies を configure します
  4. Image Scanning: container images の vulnerabilities を scan します
  5. Secret Management: secrets を安全に管理します

EKS-Specific Best Practices ​

  1. Use Managed Add-ons: 可能な場合は EKS managed add-ons を使用します
  2. Use IRSA: per-pod IAM permission management には IRSA を使用します
  3. VPC CNI Configuration: networking requirements に応じて VPC CNI を configure します
  4. Security Groups: 適切な security groups を configure します
  5. Cost Optimization: 適切な instance types と sizes を選択します

Conclusion ​

Kubernetes は、基本機能を拡張および customize するためのさまざまな extension points を提供します。Custom resources、operators、admission controllers、API server extensions、scheduler extensions、CSI、CNI、device plugins により、Kubernetes をさまざまな environments と requirements に適応させることができます。

Amazon EKS はこれらの extension features を support し、さらに EKS add-ons、ACK、AWS Load Balancer Controller、IRSA などの AWS-specific features を提供して、Kubernetes と AWS services の統合を簡素化します。

Kubernetes extension features を実装する際は、standard interfaces の使用、declarative API design、least privilege principle などの best practices に従うことが重要です。これにより、stable で scalable な Kubernetes environments を構築できます。

Quiz ​

この章で学んだ内容を確認するには、Extending Kubernetes Quiz を試してください。