> For the complete documentation index, see [llms.txt](https://atomoh.gitbook.io/kubernetes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atomoh.gitbook.io/kubernetes/jp/kubernetes-no/11-extending-kubernetes.md).

# 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](#kubernetes-extension-overview)
2. [Custom Resources](#custom-resources)
3. [Operator Pattern](#operator-pattern)
4. [Admission Controllers](#admission-controllers)
5. [API Server Extensions](#api-server-extensions)
6. [Scheduler Extensions](#scheduler-extensions)
7. [Cloud Controller Manager](#cloud-controller-manager)
8. [CSI (Container Storage Interface)](#csi-container-storage-interface)
9. [CNI (Container Network Interface)](#cni-container-network-interface)
10. [Device Plugins](#device-plugins)
11. [Extension Features in Amazon EKS](#extension-features-in-amazon-eks)
12. [Best Practices](#best-practices)
13. [Conclusion](#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 を示しています。

```mermaid
flowchart TD
    User[User/Client] --> API[API Server]

    subgraph "API Extensions"
        API --> CR[Custom Resources]
        API --> AC[Admission Controllers]
        API --> AE[API Server Extensions]
    end

    subgraph "Controller Extensions"
        CR --> OP[Operators]
        API --> CCM[Cloud Controller Manager]
    end

    subgraph "Scheduling Extensions"
        API --> SCH[Scheduler Extensions]
    end

    subgraph "Node Extensions"
        Node[Node] --> CSI[CSI Drivers]
        Node --> CNI[CNI Plugins]
        Node --> DP[Device Plugins]
    end

    API --> Node

    classDef k8sComponent fill:#326CE5,stroke:#333,stroke-width:1px,color:white;
    classDef userApp fill:#00C7B7,stroke:#333,stroke-width:1px,color:white;
    classDef default fill:#f9f9f9,stroke:#333,stroke-width:1px,color:black;

    class API,CR,AC,AE,OP,CCM,SCH,Node k8sComponent;
    class User userApp;
    class CSI,CNI,DP default;
```

### 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 がどのように機能するかを示しています。

```mermaid
flowchart TD
    User[User] --> |1. Create/Update| CRD[Custom Resource Definition]
    User --> |2. Create/Update| CR[Custom Resource Instance]

    CRD --> |Defines| CR

    subgraph "Kubernetes API Server"
        CRD
        CR
        API[API Registration]
        VAL[Validation]
        STOR[(etcd Storage)]
    end

    CRD --> |Registers| API
    CR --> |Validates| VAL
    CR --> |Stores| STOR

    classDef k8sComponent fill:#326CE5,stroke:#333,stroke-width:1px,color:white;
    classDef userApp fill:#00C7B7,stroke:#333,stroke-width:1px,color:white;
    classDef dataStore fill:#3B48CC,stroke:#333,stroke-width:1px,color:white;
    classDef default fill:#f9f9f9,stroke:#333,stroke-width:1px,color:black;

    class CRD,CR,API,VAL k8sComponent;
    class User userApp;
    class STOR dataStore;
```

### 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 がどのように機能するかを示しています。

```mermaid
flowchart TD
    User[User] --> |1. Create/Update| CR[Custom Resource]

    subgraph "Kubernetes API Server"
        CR
        STOR[(etcd Storage)]
    end

    CR --> |Stores| STOR

    subgraph "Operator"
        CTRL[Controller] --> |2. Watch| CR
        CTRL --> |3. Check Status| CR
        CTRL --> |6. Update Status| CR
    end

    CTRL --> |4. Determine Action| ACT[Action]
    ACT --> |5. Execute| K8S[Kubernetes Resources]

    classDef k8sComponent fill:#326CE5,stroke:#333,stroke-width:1px,color:white;
    classDef userApp fill:#00C7B7,stroke:#333,stroke-width:1px,color:white;
    classDef dataStore fill:#3B48CC,stroke:#333,stroke-width:1px,color:white;
    classDef default fill:#f9f9f9,stroke:#333,stroke-width:1px,color:black;

    class CR,K8S k8sComponent;
    class User userApp;
    class STOR dataStore;
    class CTRL,ACT default;
```

### 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
```

### Popular Operators

人気のある 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 がどのように機能するかを示しています。

```mermaid
sequenceDiagram
    participant User
    participant Auth as Authentication<br/>Authorization
    participant MAC as Mutating<br/>Admission Controller
    participant MWH as Mutating Webhook
    participant VAC as Validating<br/>Admission Controller
    participant VWH as Validating Webhook
    participant API as API Processing
    participant STOR as etcd Storage

    User->>Auth: 1. API Request
    Auth->>MAC: 2. Request Passes
    MAC-->>MWH: Webhook Call
    MWH-->>MAC: Response
    MAC->>VAC: 3. Mutated Request
    VAC-->>VWH: Webhook Call
    VWH-->>VAC: Response
    VAC->>API: 4. Validated Request
    API->>STOR: 5. Store
```

### 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)
}
```

### Popular Admission Controller Projects

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 を示しています。

```mermaid
flowchart TD
    User[User] --> |1. Create| PVC[PersistentVolumeClaim]

    subgraph "Kubernetes Components"
        PVC --> |References| SC[StorageClass]
        SC --> |Specifies| PROV[CSI External Provisioner]
        PROV --> |2. Volume Create Request| CSI[CSI Driver]
        CSI --> |3. Create Volume| PV[PersistentVolume]
        PV --> |Binds| PVC

        POD[Pod] --> |Mount Request| PVC
        CSI --> |4. Mount Volume| POD
    end

    subgraph "CSI Driver"
        CSI --> CTRL[Controller Service]
        CSI --> NODE[Node Service]
    end

    CTRL --> |5. Volume Management| STOR[(Storage System)]
    NODE --> |6. Volume Mount| STOR

    classDef k8sComponent fill:#326CE5,stroke:#333,stroke-width:1px,color:white;
    classDef userApp fill:#00C7B7,stroke:#333,stroke-width:1px,color:white;
    classDef dataStore fill:#3B48CC,stroke:#333,stroke-width:1px,color:white;
    classDef default fill:#f9f9f9,stroke:#333,stroke-width:1px,color:black;

    class PVC,SC,PROV,PV,POD k8sComponent;
    class User userApp;
    class STOR dataStore;
    class CSI,CTRL,NODE default;
```

### 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
```

### Popular CSI Drivers

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 を示しています。

```mermaid
flowchart TD
    subgraph "Kubernetes Components"
        API[API Server] --> |Pod Creation| KUB[kubelet]
        KUB --> |1. Create Container| CRI[Container Runtime]
        CRI --> |2. Network Setup Request| CNI[CNI Plugin]
    end

    subgraph "CNI Plugin"
        CNI --> |3. IP Allocation Request| IPAM[IPAM Plugin]
        CNI --> |5. Network Setup| NET[Network Configuration]
    end

    IPAM --> |4. IP Allocation| IPPOOL[(IP Pool)]
    NET --> |6. Apply Network Config| POD[Pod Network]

    classDef k8sComponent fill:#326CE5,stroke:#333,stroke-width:1px,color:white;
    classDef userApp fill:#00C7B7,stroke:#333,stroke-width:1px,color:white;
    classDef dataStore fill:#3B48CC,stroke:#333,stroke-width:1px,color:white;
    classDef default fill:#f9f9f9,stroke:#333,stroke-width:1px,color:black;

    class API,KUB,CRI,POD k8sComponent;
    class IPPOOL dataStore;
    class CNI,IPAM,NET default;
```

### 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" }
    ]
  }
}
```

### Popular CNI Plugins

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
```

### Popular Device Plugins

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 を示しています。

```mermaid
flowchart TD
    subgraph "Amazon EKS"
        EKS[EKS Cluster] --> |Manages| CP[Control Plane]
        EKS --> |Manages| NG[Node Groups]

        subgraph "EKS Add-ons"
            CP --> VCNI[Amazon VPC CNI]
            CP --> CDNS[CoreDNS]
            CP --> KP[kube-proxy]
            CP --> EBSCSI[Amazon EBS CSI Driver]
            CP --> ALBC[AWS Load Balancer Controller]
        end
    end

    subgraph "AWS Services"
        VCNI --> VPC[Amazon VPC]
        EBSCSI --> EBS[Amazon EBS]
        ALBC --> ELB[Elastic Load Balancing]

        IAM[AWS IAM] --> |IRSA| NG
        ACK[AWS Controllers for Kubernetes] --> AWS[AWS Services]
    end

    classDef k8sComponent fill:#326CE5,stroke:#333,stroke-width:1px,color:white;
    classDef awsService fill:#FF9900,stroke:#333,stroke-width:1px,color:black;
    classDef default fill:#f9f9f9,stroke:#333,stroke-width:1px,color:black;

    class EKS,CP,NG,VCNI,CDNS,KP,EBSCSI,ALBC,ACK k8sComponent;
    class VPC,EBS,ELB,IAM,AWS awsService;
```

### 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](/kubernetes/jp/kuizu/quizzes/11-extending-kubernetes-quiz.md) を試してください。