Confluent Operator 用の Kubernetes クラスターの準備¶

このガイドでは、Confluent Operator で Confluent Platform デプロイメント用の Kubernetes クラスターを準備するタスクについて説明します。このタスクを実施するユーザーには、Kubernetes クラスターレベルのアクセス許可が必要です。

このガイドの例では、以下が想定されています。

$VALUES_FILE は「グローバル構成ファイルの作成」でセットアップする構成ファイルのことです。
Operator ドキュメントで簡潔で明快な例を提示できるよう、すべての構成パラメーターが構成ファイル（ $VALUES_FILE ）に指定されます。ただし、本稼働環境でのデプロイにおいて、Helm を使用して機密データを扱う場合には、--set または --set-file オプションを使用します。以下に例を示します。
```
helm upgrade --install kafka \
 --set kafka.services.mds.ldap.authentication.simple.principal="cn=mds\,dc=test\,dc=com" \
 --set kafka.services.mds.ldap.authentication.simple.credentials=”Developer!” \
 --set kafka.enabled=true
```
Copy
operator は Confluent Platform のデプロイ先となる名前空間です。
コマンドはすべて、Confluent Operator のダウンロード先ディレクトリにある helm ディレクトリで実行されます。

Confluent Platform の名前空間の作成¶

Confluent Platform のデプロイ先となる Kubernetes 名前空間を作成します。

kubectl create namespace <namespace-name>
Copy

名前空間を使用するデプロイに必要なアクセス許可の付与¶

クラスターレベルのアクセス許可のないユーザーが名前空間に Operator と Confluent Platform をデプロイできるようにするには、Operator と Confluent Platform のデプロイ前に、以下のタスクを Kubernetes クラスター管理者 として実行します。このセクションのスニペットでは、operator 名前空間を使用します。

以下のコマンドを使用して Confluent Operator CRD をプレインストールします。
```
kubectl apply -f <Operator home directory>/resources/crds -n operator
```
Copy

名前空間を使用するデプロイに必要なアクセス許可のある rolebinding.yaml ファイルを作成します。

内容には、必要最小限のアクセス許可が含まれています。必要となることが考えられるリソースアクセス許可が他にあれば追加します。

ロールとロールバインディングは、Operator と同じ名前空間にあることが必要です。

ロールバインディングの subject は、所定の名前空間に存在するユーザー/アカウントであることが必要です。

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    component: operator
  name: cc-operator
  namespace: operator
rules:
- apiGroups:
  - cluster.confluent.com
  resources:
  - '*'
  verbs:
  - '*'
- apiGroups:
  - operator.confluent.cloud
  resources:
  - '*'
  verbs:
  - '*'
- apiGroups:
  - policy
  resources:
  - poddisruptionbudgets
  verbs:
  - '*'
- apiGroups:
  - apps
  resources:
  - deployments
  - deployments/scale
  - deployments/status
  - replicasets
  - replicasets/scale
  - replicasets/status
  - statefulsets
  - statefulsets/scale
  - statefulsets/status
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - events
  - persistentvolumeclaims
  - pods
  - pods/exec
  - secrets
  - services
  - serviceaccounts
  verbs:
  - '*'
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  labels:
    component: operator
  name: operator-cc-operator
  namespace: operator
subjects:
- kind: ServiceAccount
  name: cc-operator
  namespace: operator
roleRef:
  kind: Role
  name: cc-operator
  apiGroup: rbac.authorization.k8s.io
Copy

以下のコマンドを使用して、必要なアクセス許可をサービスアカウント cc-operator に付与するためのロールとロールバインディングを作成します。cc-operator サービスアカウントにより、Operator と Confluent Platform がインストールされます。
```
kubectl apply -f rolebinding.yaml -n operator
```
Copy
以下のファイルを <Operator home directory>/helm/confluent-operator/charts/operator/templates ディレクトリから削除します。
- clusterrole.yaml
- clusterrolebinding.yaml

静的にプロビジョニングされるディスクのセットアップ¶

Confluent Operator 5.5 以降、作成されるすべての PersistentVolume で特定の StorageClass を使用するよう Operator に指示できます。

ストレージを動的にはプロビジョニングできず、ディスクを前もって静的にプロビジョニングする必要のある Kubernetes クラスターがある場合、Confluent Operator では省略可能です。

Kubernetes の StorageClass をローカルプロビジョニング用に構成します。以下に例を示します。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-storage-class
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
Copy

作成することになる Kafka ブローカーインスタンスごとに、以下を決定します。
- 配置先となるワーカーノード。
- ブローカーインスタンスに公開される PersistentVolume として使用予定の、配置先ワーカーノードのホストファイルシステム上のディレクトリパス。
目的のホストパスと目的のワーカーノードのホスト名ラベルとを持つ PersistentVolume を、こちらの説明に従って作成します。
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-1                             ----- [1]
spec:
  capacity:
    storage: 1Gi                        ------ [2]
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain  ----- [3]
  storageClassName: my-storage-class     ------[4]
  local:
     path: /mnt/data/broker-1-data       ----- [5]
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - ip-172-20-114-199.ec2.internal --- [6]
```
Copy
- [1] PersistentVolume の名前を選択します。
- [2] 各 Kafka ブローカーインスタンスについて、必要なストレージ以上のストレージサイズを選択します。
- [3] Operator によって最終的に作成され、Kubernetes によって最終的にこの PersistentVolume とバインドされるデータを、PersitentVolumeClaim の削除後も保持する場合は Retain を選択します。
  
  PersistentVolumeClaim が削除される際にこのデータをガベージコレクションの対象にする場合は、Delete を選択します。
  
  重要
  
  persistentVolumeReclaimPolicy: Delete を使用すると、ポッドを削除するときにボリューム上のデータが削除され、結果としてその永続ボリュームも削除されます。
- [4] storageClassName が、構成ファイル（$VALUES_FILE）に指定した global.storage.storageClassName と一致している必要があります。
- [5] これが、永続的なデータボリュームとしてブローカーのワーカーノード上で使用するディレクトリパスです。
- [6] これが、このブローカーインスタンスのホストとして使用するワーカーノードの kubernetes.io/hostname ラベルの値です。ホスト名は以下のようにして確認します。
```
kubectl get nodes -o 'custom-columns=NAME:metadata.name,HOSTNAME:metadata.labels.kubernetes.io/hostname'

NAME       HOSTNAME
node-1     ip-172-20-114-199.ec2.internal
```
  Copy
作成予定のブローカーごとに、ステップ 2 と 3 を繰り返します。これは、構成ファイル（ $VALUES_FILE ）の kafka.replicas フィールドによって決まります。