このロールは、Kubernetesクラスターを完全に自動化された冪等の実装でいくつかのコンポーネントとともにデプロイするために使用できます。

特徴

このロールは、次のすべての機能を有効にするように構成できます：

• HAProxyおよびKeepalivedを使用したシングルまたはマルチコントロールプレーンクラスターの実装により、高可用性を実現。

• FlannelおよびCalicoによるマルチネットワークアドオン。

• Kubernetes ダッシュボード。

• 証明書の生成とkubeconfigファイルの更新を伴うユーザー管理。

• Ceph-CSIストレージクラスのブロックデバイス。

• MetalLBロードバランサーのベアメタル環境用。

• サービス公開のためのIngress NGINX。

• 自動証明書管理のためのCert Manager。

Ansibleプレイブックでクラスターをインストール

環境を準備する最良の方法は、Pythonの仮想環境を使用し、pip3を使ってansibleをインストールすることです：

user@lab ~ # python3 -m venv ansible
user@lab ~ # source ansible/bin/activate
(ansible) user@lab ~ # pip3 install ansible

次に、このロールが必要で、ansible-galaxyを使用することがすべて自動化される良い選択です：

(ansible) user@lab ~ # ansible-galaxy install mmul.kubelab -p ansible/roles/

ロールが設置されたら、再度pip3を使って要件を完了します：

(ansible) user@lab ~ # pip3 install -r ansible/roles/mmul.kubelab/requirements.txt

要件が準備できたら、通常は次のようにtests/kubelab.ymlプレイブックを起動してロールを使用します：

(ansible) user@lab ~ # ansible-playbook -i tests/inventory/kubelab tests/kubelab.yml

注意: 関与するシステムの日付と時間が重要です！ Ansibleプレイブックを実行しているマシンと宛先のマシン間でクロックのズレがあると、証明書の検証が失敗する可能性があります。

注意: いつでもk8s_resetをtrueとして渡すことで、すべてをリセットすることができます。これによりクラスター全体がリセットされるので、注意して使用してください：

(ansible) user@lab ~ # ansible-playbook -i tests/inventory/kubelab tests/kubelab.yml -e k8s_reset=true

インストール後のクラスターとの対話

プレイブックの実行が完了したら、クラスターと対話する最良の方法は、次のようにkubectlコマンドを使用することです：

user@lab ~ # curl -s -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

user@lab ~ # chmod +x kubectl

user@lab ~ # sudo mv kubectl /usr/local/bin

Kubernetesロールは、admin.confという名前の主要なkubeconfigファイルを含むローカルディレクトリを生成します。これを使用する最も簡単な方法は、KUBECONFIG変数をエクスポートすることです：

user@lab ~ # export KUBECONFIG=~/kubernetes/admin.conf

これ以降、セッションが終了するまで、kubectlを使用するたびに、そのファイルに含まれる認証情報に依存します：

user@lab ~ # kubectl cluster-info

さまざまなユーザーを使用してクラスターにログインすることも可能です。詳細はユーザーセクションを参照してください。

設定

インベントリ

典型的なインベントリは、デプロイしたいものに依存します。例のkubelabを見て、次のようにホストファイルにノードを宣言できます：

[kubelab]
kubernetes-1 k8s_role=control-plane run_non_infra_pods=true
kubernetes-2 k8s_role=control-plane run_non_infra_pods=true
kubernetes-3 k8s_role=control-plane run_non_infra_pods=true
kubernetes-4 k8s_role=worker

どのノードがコントロールプレーンとして機能するか、またそれらが非インフラポッドを実行するかどうかを設定します。次に、グループファイルの中で、実装したい内容に応じて追加の設定を定義します。

Kubernetesホストのホストグループ名はデフォルトでkubelabですが、k8s_host_group変数を宣言することでオーバーライドできます。

Kubernetesクラスター

マルチコントロールプレーンの高可用性クラスターを実装したい場合は、次の変数を指定する必要があります：

k8s_cluster_name: kubelab

k8s_control_plane_node: kubernetes-1
k8s_control_plane_port: 6443
k8s_control_plane_cert_key: "91bded725a628a081d74888df8745172ed842fe30c7a3898b3c63ca98c7226fd"

k8s_multi_control_plane: true
k8s_balancer_VIP: 192.168.122.199
k8s_balancer_interface: eth0
k8s_balancer_port: 8443
k8s_balancer_password: "d6e284576158b1"

k8s_wait_timeout: 1200

k8s_control_plane_ports:
  - 2379-2380/tcp
  - 6443/tcp
  - 8443/tcp
  - 10250/tcp
  - 10257/tcp
  - 10259/tcp

これにより、kubernetes-1ノードから始まり、マルチコントロールプレーンを有効にし、VIPアドレスとインターフェースを設定したクラスターが立ち上がります。

注意: k8s_control_plane_cert_keyとk8s_balancer_passwordの両方を変更して、セキュリティを強化してください。

他にもポッドのネットワークCIDR、ワーカーポート、ノードポート範囲、ファイアウォール管理などをより単位的に設定する方法があります。詳細についてはデフォルトファイルを確認できます。

ネットワークアドオン

KubernetesロールはFlannelおよびCalicoのネットワークアドオンをサポートしています。設定は、実装したいアドオンに依存します。

Flannelでは次のようにします：

# Flannelアドオン
k8s_network_addon: flannel
k8s_network_addon_ports:
  - 8285/udp
  - 8472/udp

Calicoを実装する方法についてはデフォルトファイルを確認してください。

ダッシュボード

Kubernetesダッシュボードは、次の設定を追加することで実装できます：

k8s_dashboard_enable: true

インストールが完了すると、ダッシュボードにアクセスする最も簡単な方法は、kubectl proxyを使用して、次のURLにアクセスすることです： http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/。

ログインプロンプトが表示され、トークンを渡すことでログインできます。デフォルトではKubernetesロールがdashboard-userという名前のユーザーを作成します（これをオーバーライドできます）。

トークンを取得するには、kubectlを使用してください：

user@lab ~ # kubectl -n kubernetes-dashboard create token dashboard-user
<YOUR TOKEN>

上記のコマンドの出力をプロンプト内にコピー＆ペーストすれば、ログインは完了です。

ユーザー

クラスターにユーザーを追加することができます。次のように宣言します：

k8s_users:
  - name: pod-viewer
    namespace: default
    role_name: pod-viewer-role
    role_rules_apigroups: '""'
    role_rules_resources: '"pods","pods/exec","pods/log"'
    role_rules_verbs: '"*"'
    rolebinding_name: pod-viewer-rolebinding
    cert_expire_days: 3650
    update_kube_config: true

これにより、次のようなファイルを含むローカルディレクトリが作成されます：

user@lab ~ # ls -1 kubernetes/users/
pod-viewer.crt
pod-viewer.csr
pod-viewer.key
users.conf
users-rolebindings.yaml
users-roles.yaml

users.confファイルは、このユーザーでクラスターにアクセスするために使用できます：

user@lab ~ # export KUBECONFIG=~/kubernetes/users/users.conf

Ceph CSI

KubernetesロールはCeph CSIストレージクラスの実装をサポートしています。次のように定義できます：

k8s_ceph_csi_enable: true
k8s_ceph_csi_id: lab-ceph
k8s_ceph_csi_secret_userid: kubernetes
k8s_ceph_csi_secret_userkey: AQAWvU5jjBHSGhAAuAXtHFt0h05B5J/VHERGOA==
k8s_ceph_csi_clusterid: d046bbb0-4ee4-11ed-8f6f-525400f292ff
k8s_ceph_csi_pool: kubepool
k8s_ceph_csi_monitors:
  - 192.168.122.11:6789
  - 192.168.122.12:6789
  - 192.168.122.13:6789

新しいPVCを宣言することができます：

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rbd-pvc
  namespace: rasca
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc

関連するPodを次のように定義できます：

---
apiVersion: v1
kind: Pod
metadata:
  name: csi-rbd-demo-pod
  namespace: rasca
spec:
  containers:
    - name: web-server
      image: nginx
      volumeMounts:
        - name: mypvc
          mountPath: /var/lib/www/html
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        claimName: rbd-pvc
        readOnly: false

注意: 現時点ではrbdプロビジョニングのみがサポートされています。

MetalLB

MetalLBは、ベアメタルKubernetesクラスター用のロードバランサーの実装を提供しています。標準のルーティングプロトコルを使用して有効にするには、次のように宣言するだけで済みます：

k8s_metallb_enable: true
k8s_metallb_pools:
  - name: 'first-pool'
    addresses: '192.168.122.100-192.168.122.130'

このロードバランサーを使用して、宣言したプール範囲内でIPを作成できます（次のingress-nginxの例を確認して理解してください）。

Ingress NGINX

Ingress NGINXを有効にするには、単に次のように宣言します：

k8s_ingress_nginx_enable: true

これにより、NGINXをリバースプロキシおよびロードバランサーとして使用したIngressコントローラーがインストールされます。

コントロールプレーンでのIngress NGINX

例えば、HAProxyが管理するバランスIPで80と443ポートを公開するためにIngress NGINXを使用することができます：

k8s_ingress_nginx_enable: true
k8s_ingress_nginx_haproxy_conf: true
k8s_ingress_nginx_services:
  - name: ingress-nginx-externalip
    spec:
      externalIPs:
      - 192.168.122.199
      ports:
      - name: port-1
        port: 80
        protocol: TCP
      - name: port-2
        port: 443
        protocol: TCP
      selector:
        app.kubernetes.io/component: controller
        app.kubernetes.io/instance: ingress-nginx
        app.kubernetes.io/name: ingress-nginx

これにより、バランスされたIP（この場合は192.168.122.199）で両方のポートが公開され、そのサービスが応答を返すようになります。

テストするには、次のようにします：

$ kubectl create deployment demo --image=httpd --port=80

TLSのテスト方法は次の通りです：

$ kubectl create deployment demo --image=httpd --port=80

すべての設定が完了し、アプリケーションを公開したい場合、次のようなYAMLファイルを使用してテストします：

apiVersion: v1
kind: Namespace
metadata:
  name: rasca
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: index-html
  namespace: rasca
data:
  index.html: |
    これは私の素晴らしいWebサーバーです！
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: rasca
  labels:
    app: nginx
spec:
  containers:
    - name: web-server
      image: nginx
      volumeMounts:
      - name: docroot
        mountPath: /usr/share/nginx/html
  volumes:
    - name: docroot
      configMap:
        name: index-html
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  namespace: rasca
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
  name: nginx-ingress
  namespace: rasca
spec:
  ingressClassName: nginx
  rules:
  - host: nginx.apps.kubelab.mmul.it
    http:
      paths:
      - backend:
          service:
            name: nginx-service
            port:
              number: 80
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - nginx.apps.kubelab.mmul.it
    secretName: nginx.apps.kubelab.mmul.it

ライセンス

MIT

著者情報

Raoul Scarazzini (rascasoft)