Kubernetesのマニフェストを それなりにCIしたい CircleCI User Community Meetup #2 Osaka @stormcat24

whois ‣ CyberAgent, Inc. ‣ Backend Engineer ‣ OpenSaaS Studio Tech Lead ‣ Docker/Kubernetes 実践コンテナ開発入門 Akinori Yamada stormcat24

book 1万部突破ベストセラー Docker/Kubernetes 実践コンテナ開発入門 （技術評論社） ※CircleCIについても触れています

この後、紀伊國屋書店へGo

場所提供をしたので 喋ることにしました

Kubernetesでの アプリケーション開発

予備知識：Pod Pod Dockerコンテナの集合体 nginx api

Podを複製 Deployment ReplicaSet Pod Pod Pod 予備知識：Deployment ReplicaSetの世代管理 基本的に、開発者はアプリケーションの デプロイ定義として、Deploymentリソースを定義・管理します

apiVersion: apps/v1 kind: Deployment metadata: name: echo labels: app: echo spec: replicas: 3 selector: matchLabels: app: echo template: metadata: labels: app: echo spec: containers: - name: echo image: gcr.io/your-organization/your-service:v0.0.1-01-g39f376a env: - name: HOGE value: fuga ports: - containerPort: 8080 マニフェストファイル deployment.yaml ※マニフェストファイルを Kubernetesクラスタに適用=デプロイ

Kubernetesにおける CI/CD

CIとCDは明確に分離し、 GitOpsなスタイルが潮流 アプリケーション リポジトリ デリバリ用リポジトリ ※Kubernetesの マニフェストファイル群を置く

CDの手法は色々ある ‣ CircleCIからkubectl ‣ Spinnaker ‣ ArgoCD ‣ Flux CD ‣ ローカルから直接kubectl

GitOpsスタイルのCD デリバリ用リポジトリ ≒ リポジトリへの変更がクラスタへのデプロイ 事実上、クラスタ操作をPRで行うことになる

CI CD ユニットテスト アプリケーションビルド Dockerイメージビルド DockerレジストリへPush クラスタの状態をsync マニフェストをクラスタに反映

課題感

CI CD ユニットテスト アプリケーションビルド Dockerイメージビルド DockerレジストリへPush クラスタの状態をsync マニフェストをクラスタに反映 マニフェストの検証が なされずに反映

apiVersion: apps/v1 kind: Deployment metadata: name: echo labels: app: echo spec: replicas: 3 selector: matchLabels: app: echo template: metadata: labels: app: echo spec: containers: - name: echo image: gcr.io/your-organization/your-service:v0.0.1-01-g39f376a env: - name: HOGE value: fuga ports: - containerPort: 8080 PRでの人力レビューには限界がある

アプリケーションは ユニットテストを含め検証の手法が豊富

マニフェストファイルもそうあるべきでは？

+

kind = Kubernetes in Docker CircleCI上に Kubernetesクラスタを構築できる

version: 2 jobs: kind: machine: image: circleci/classic:201808-01 steps: - checkout - run: name: Install kubernetes cluster with kind command: | curl -Lo ./kind https://github.com/kubernetes-sigs/kind/releases/download/v0.6.1/kind- linux-amd64 chmod +x kind sudo mv kind /usr/local/bin - run: name: Start cluster command: | kind create cluster --name test-cluster --image kindest/node:v1.14.9 - run: name: Waiting for ready command: | READY="" while [ "$READY" != "True" ] do sleep 2 READY=`kubectl get node -o=jsonpath='{range .items[*]}{range @.status.conditions[? (@.type == "Ready")]}{@.status}{end}{end}'` done echo "Node is ready" echo "Current running pods are the follows:" kubectl get --all-namespaces pod machineモードで kindインストール クラスタ起動　 クラスタ起動待ち

クラスタ起動

これでCircleCIの中で Kubernetesクラスタに いろいろできる

考えられるワークロード ‣ マニフェストの反映でエラーでないかチェック ‣ 実行時エラー確認 ‣ マニフェスト反映 → クラスタに対してE2Eテストの実行 ‣ マニフェストの妥当性のチェック ‣ Open Policy Agent(OPA) / gatekeeper ‣ 必須なlabelやannotationのチェック ‣ イメージや環境変数のチェック etc

CI (CDのCIと）CD ユニットテスト アプリケーションビルド Dockerイメージビルド DockerレジストリへPush クラスタの状態をsync マニフェストをクラスタに反映 マニフェスト妥当性チェック ※これからはCDのCIが大事

まとめ ‣ CircleCI + kindで気軽に揮発的なKubernetesクラスタが作れる ‣ OPAやgatekeeperで、制約を設けることでPRレビューで漏れがちなミ スをチェックしやすくなる ‣ GitOpsの推進と、デプロイの心理的安全性の確保 ‣ アプリケーションが巨大（マイクロサービスとか）になると、CircleCI で全てのリソースを展開することが難しい

おわり