Kubernetes Meetup Tokyo #21 Cloud Native CI/CD 参加レポート Kubernetes Meetup Tokyo \#21にブログ枠で参加してきました。
今回はCloud Native CI/CDがテーマということで、CI/CDツールや CI/CDで扱いに困るSecretに関するツールの紹介がありました。
個人的にSpinnakerを調べていることもあり、どのセッションも大変興味深かったです。
全体的には、CI/CDにまつわるアレコレをCRD + Custom Controllerで実現しよう!という方向性を感じました。
以下、セッションごとの感想です。
セッション1: Argoプロジェクト最新動向
Speaker: DAISUKE TANIWAKI (@dtaniwaki), Preferred Networks, Inc.
Argo ProjectのApproverである@dtaniwakiさんによる、
Argo CD、Argo Rolloutsを中心としたArgoプロジェクトの概要紹介でした。
Argo CDは指定したGitリポジトリのマニフェストの内容を監視してクラスタと同期させる、
というシンプルな方針で作られていて、とても使いやすそうに感じました。
リソースの一部のみのデプロイ・ロールバックもサポートされているとのことでしたが、
どうやって実現しているかまでは分からなかったので、あとできちんと調べてみようと思います。
Argo Rolloutsは通常のDeploymentリソースでは実現できないデプロイ戦略を実現するためのツールで、
CRDとして実装されているとのことでした。
現時点では、Blue/Greenデプロイ、カナリーリリースをサポートしており、
今後はA/Bテストのサポートも予定しているそうです。
RolloutカスタムリソースはDeploymentリソースとほぼ同じ構成でストラテジーの部分のみ異なる作りになっており、
まさに欲しかったものはこれ!と感じました。
ただ、カナリーリリースでのリクエスト振り分けはPod数の割合でしか指定できず、
Istioのように細かい制御ができないので、Pod数が少ない場合には中々難しそうです。
後述のFlaggerのように、Istioとの連携ができるような機能もあるといいのかもしれません。
余談ですが、Argoの名前はギリシア神話のアルゴー船から来ているとのことで、
FGO勢としてはなるほど!と納得したのでした。
セッション2: GitOpsでも秘匿情報をバッチリ扱う方法、SealedSecretsとは?
Speaker: Ryuichi Ito (@amaya382), SAKURA internet Inc.
さくらインターネットの@amaya382さんによる、
SecretをGit管理できるようにするためのSealedSecretというツールの紹介でした。
クラスタ上にキーペアを生成し、手元でその公開鍵を参照して暗号化したカスタムリソースを生成、
そのカスタムリソースをCustom Controllerがクラスタ上の秘密鍵で復号するという仕組みだそうです。
k8sっぽい思想で作られていて素晴らしいと感じました。
ただ、暗号化する際にクラスタ上の公開鍵を参照するためにkubeconfigの情報を用いているため、
暗号化できる環境が限られていることから、ワークフローが結構難しそうです。
コミットする前に暗号化しなければならないのですが、
開発者の手元にkubeconfigの情報が必ずあるかというとそうとは限らないことの方が多いと思いますし、
だからといってCIで暗号化しようと思っても平文Secretをコミットするわけにはいきません。
現実解としては特定の人だけが機密情報を設定するという運用対処でしょうか。
また、暗号化するためにはSecretのマニフェストが必要になるため、HelmやKustomizeとの相性がよくないとの説明もありました。
ここは資料にもある通り、頑張るしかないようです。
そのほか、SealedSecrets以外の秘匿情報管理ツールについても紹介がありました。
多種多様なツールがあルため、メリデメをきちんと考慮してツールを選択する必要がありそうです。
余談ですが、個人的に「GitOpsでCIがPullReqを作るためのアレ」を作っているそうで、
どんなものかとても気になります。
GitOpsを真面目にやろうとすると必ず必要になるアレですが、
自分の環境ではCloud build + hub + shell scriptで泥臭くやっています…。
セッション3: コロプラが実践しているSpinnakerを用いたデプロイ戦略
Speaker: Kenta Iso (@go_vargo), COLOPL, Inc
Presentation:
コロプラの@go_vargoさんによる、コロプラにおけるSpinnakerの活用事例の紹介でした。
GKE上でSpinnakerのほか、Helm、GitLab CIを使ってCI/CDを実現しているとのことで、
ゲームタイトル1つにつきクラスタ1つ、クラスタ1つにつきSpinnaker1つ、という構成でした。
GitLab CIがコンテナイメージをビルドしてGCRにプッシュしつつ、
Helm templateでマニフェストを生成してGCSにアップロードし、
SpinnakerはGCRへのイメージプッシュをトリガーとしてデプロイを行うパイプラインとなっています。
どの環境にデプロイするかはイメージのタグで管理されており、
マニフェストリポジトリのブランチと環境を対応させる方法と比べ、そのほうがシンプルな構成になるなぁと感じました。
デプロイ用のパイプラインのほか、アプリごとにかなりの数のパイプラインを定義していて、
ブランチを作成すると対応する環境を自動作成するパイプラインなどもあるそうです。便利。
Spinnakerは1年以上運用されているということで、
運用していく上での様々な工夫や苦労点が紹介されていてとても参考になりました。
特にチューニングやHA構成は公式ドキュメントだけでは全然分からないので、
こういった知見を共有してもらえるのは大変助かります。
CloudDriverが定期的にエラーを吐くのはSpinnakerユーザにとってはお馴染みの仕様(?)です。
マルチクラスタ対応している場合に1つのクラスタを消すと他のクラスタにもデプロイできなくなる、
というのは初めて知りました。
LT1: Argo CD 実践ガイド
Speaker: @ponde_m
Argo CDの紹介でした。
最初のセッションと被らないような話になっていて、
Application of Applicationsパターンの紹介や、Sync Wavesによるマニフェスト順序の制御の話がありました。
Application of Applicationsの話は、なんとなく便利そうだけどなるほど分からん、という感じだったので
あとでちゃんと調べてみたいです。
LT2: Flux/Flaggerでカナリアリリースする
Speaker: @shohehe_y
Presentation:
Flux/Flaggerによるカナリーリリースの実現方法の紹介でした。
最初のセッションのArgo Rolloutsと同様、カスタムリソースによってカナリーリリースを定義しており、
あらゆるものがカスタムリソースで提供されていく機運が高まっているようです。
Argo Rolloutsと異なるのは、Istioとの連携を前提にしており、
リクエストの振り分けをIstioの機能で細かく制御できる点です。
Pod数が少ない場合やIstioを使っている場合にはFlaggerの方が良さそうな感じがしました。
LT3: KubeflowPipelineを用いたモデルライフサイクル
Speaker: me7te7or
Presentation:
KubeflowPipelineの紹介でした。
機械学習のワークフロー管理はどこも工夫を凝らしているんだなぁと思いました。
最初のセッションでもPFNで機械学習のワークフローを管理知るためにArgoにコントリビュートしているとのことでしたし、
AWS Summitでも同じようなテーマの発表を見た覚えがあります。
詳しい話はGoogle Cloud Next '19 Tokyoで聞けるそうです。
LT4: Vault on Kubernetes
Speaker: kennygt51
Hashicorp Vaultをk8sに載せて使う方法の紹介でした。
Vaultを使う場合、2番目のセッションのSealedSecretsと比べると構成は複雑になりますが、
秘匿情報を集中管理できる点や、鍵を外で管理している点など、エンプラ的にはいいかもしれないと思いました。