minikubeでお手軽GitOps!

環境

今回はminikube上にargocdとgitlabをデプロイした。

• minikube
• argocd
• gitlab

ゴール

• manifestリポジトリにhelm ChartがpushされるとArgo CDによりChartがminikubeクラスタに自動デプロイされる
• manifestリポジトリの変更をArgo CDが検出し自動でクラスタに反映される

リポジトリ構成

ブランチ

開発環境ごととする。

Argo CD

Gitリポジトリ登録

リポジトリをArgo CDに登録する。今回はテスト用途でhttp接続ではあるもののローカル環境でインターネットには出ない構成としてある。

K8sクラスタの登録

デフォルトではarogocdのデプロイされているクラスタが登録されているため今回は変更不要。

アプリケーションの作成

bitnamiのwordpressをデプロイしてみる。

helmチャートのpullと展開

helm pull bitnami/wordpress
tar -xzvf wordpress-17.0.5.tgz
rm wordpress-17.0.5.tgz

manifestマニフェストリポジトリへのpush

manifestリポジトリ内のwordpressディレクトリの構造はこうなっている。

./wordpress
├── base
│   ├── Chart.lock
│   ├── Chart.yaml
│   ├── README.md
│   ├── charts
│   │   ├── common
│   │   ├── mariadb
│   │   └── memcached
│   ├── templates
│   │   ├── NOTES.txt
│   │   ├── _helpers.tpl
│   │   ├── config-secret.yaml
│   │   ├── deployment.yaml
│   │   ├── externaldb-secrets.yaml
│   │   ├── extra-list.yaml
│   │   ├── hpa.yaml
│   │   ├── httpd-configmap.yaml
│   │   ├── ingress.yaml
│   │   ├── metrics-svc.yaml
│   │   ├── networkpolicy-backend-ingress.yaml
│   │   ├── networkpolicy-egress.yaml
│   │   ├── networkpolicy-ingress.yaml
│   │   ├── pdb.yaml
│   │   ├── postinit-configmap.yaml
│   │   ├── pvc.yaml
│   │   ├── secrets.yaml
│   │   ├── serviceaccount.yaml
│   │   ├── servicemonitor.yaml
│   │   ├── svc.yaml
│   │   └── tls-secrets.yaml
│   ├── values.schema.json
│   └── values.yaml
└── overlays
    ├── dev
    ├── prd
    └── stg

　アプリケーションの作成

K8sクラスタと同期させるマニフェストが配置されているディレクトリのパスを指定する。
今回は特にカスタマイズしないのでbaseにあるものをそのまま適用する。
また、環境にあわせてパラメータを以下のとおり変更した。
GENERAL

• SYNC POLICY : Automatic
  HELM
• service.Type : ClusterIP

しばらくするとpushされたHelm Chartが検出されPoDがデプロイされた。

wordpressサービスにIngress経由でアクセスできるようになった。

PoD replica数の変更とAuto-Sync

ここではreplica setを変更し、Auto-Syncの動きをみてみる。ここではレプリカカウントを1から2に変更する。

 262 ## @param replicaCount Number of WordPress replicas to deploy
 263 ## NOTE: ReadWriteMany PVC(s) are required if replicaCount > 1
 264 ##
 265 replicaCount: 2

コミットしてmanifestリポジトリに変更をpushするとほどなくして変更がArgo CDにより検知されOutOfSyncステータスとなった。

ここでwordpress deploymentを確認するとレプリカセット数がArgo CDによって2に変更されたことがわかる。ただしこのままだと2つめのPODは起動してこないことが想定される。これはwordpressがステートフルであり、別途NFSサーバーのような共有ストレージが必要なためである。wordpressはphpや記事を構成する画像を永続ボリュームに保存する。このため2つ以上のPoDからの同時マウントをサポートする永続ボリュームが必要だ。

% kubectl get deployment
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
wordpress   1/2     2            1           28m

と考えていたが、しばらくするとふたつ目のPoDが正常に起動してきた。これには以下のような要因が考えられる。

ただし、本番環境ではキャパシティや可用性維持のため複数のノードにPoDを分散する。そのような構成では複数ノードから同時マウント可能な共有ボリューム(AWS EFS等)を用意するか、ブロックストレージを複数のノードからマウントできるようなクラスタファイルシステムの構成が別途必要となる。

　
デプロイされていたPVの定義は以下の通り。

% kubectl describe  pv pvc-bb80942d-c527-4792-b616-ea5bedfe3f00
Name:            pvc-bb80942d-c527-4792-b616-ea5bedfe3f00
Labels:          <none>
Annotations:     hostPathProvisionerIdentity: 04838c7f-a884-40c7-af29-23901879f9d2
                 pv.kubernetes.io/provisioned-by: k8s.io/minikube-hostpath
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    standard
Status:          Bound
Claim:           default/wordpress
Reclaim Policy:  Delete
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        10Gi
Node Affinity:   <none>
Message:         
Source:
    Type:          HostPath (bare host directory volume)
    Path:          /tmp/hostpath-provisioner/default/wordpress
    HostPathType:  
Events:            <none>

ステートフルセットとしてデプロイするアプリケーションの同期

ステートフルセットの場合、PV拡張といったデプロイに影響のあるマニフェストの同期は禁止されておりエラーとなる。禁止される変更は具体的には以下のような操作である。このあたりは別途確認していく。

ステートフルセットで禁止される操作:

• 'replicas'
• 'ordinals'
• 'template'
• 'updateStrategy'
• 'persistentVolumeClaimRetentionPolicy' and
• 'minReadySeconds'

おわりに

この記事ではmanifestリポジトリにpushされたマニフェストをベースにArgo CDによるK8sへのマニフェストの同期を確認した。また、今後CI/CD関連で確認したい動きは以下のとおり。

• kustomizeによる環境ごとに異なるパラメータでのアプリケーションデプロイ
• codeのCI/CD
• セキュリティ向上
  • SonarQubeを用いたcodeのチェック
  • Poralisを用いたmanifestのチェック