はじめに
ビットキーで bitkey platform を開発しています @otakakot です。
bitkey platform では CloudNative Days Tokyo 2023 「リリース速度10倍を実現したビットキー流DevOps - ArgoCD との付き合い方 - 」 で紹介したように ArgoCD を活用しています。
先日そんな ArgoCD が なんか知らんけど壊れた のでそのときの状況についてこの記事にて共有します。
本記事を通して実際に ArgoCD をどのように管理するのが適切なのか知見を共有できればと思います。
学び
不具合の概要
不具合はこちらの issue に記載されてるものになります。
argocd-redis secret-init initcontainer timeout
Describe the bug
secret-init initContainer is failing to check/init argocd/argocd-redis secret
To Reproduce
kubectl apply -k https://github.com/argoproj/argo-cd/raw/master/manifests/install.yaml
Expected behavior
InitContainer should succeed to check/init secret argocd/argocd-redis
ネットワークポリシーの設定により Redis ポッドに対してコマンドが実行できなかったことで不具合が発生していました。
こちらの不具合は以下の PR にて修正されています。
この不具合は v2.11.1 で観測しましたが現在（2024/06/05時点）はすでに該当のバージョンでも問題なく動作することを確認しています。
振り返り
我々のチームはデイリースクラムの時間を使って社内の開発環境（ bitkey platform としてはステージング環境）に手動でデプロイを実施します。
基本的には我々が管理するアプリケーションがデプロイ対象となっているのですが、 ArgoCD に関しても ArgoCD で管理する運用になっています。
そして ArgoCD のバージョンは stable で管理しています。
マニフェストだと下記の形式です。
spec:
project: default
source:
repoURL: https://github.com/argoproj/argo-cd.git
targetRevision: stable
path: manifests
directory:
include: install.yaml
この日、ArgoCD に diff があったので Sync 操作を実行しました。
しかし、 ArgoCD は一向に Healthy になりません。
ArgoCD が更新できないためアプリケーションをデプロイすることができなくなりました。
ちなみに、このバージョンにおいてゼロから ArgoCD を構築した場合でも失敗します。
我々はリリース前にミラー環境をゼロから構築するのですが ArgoCD が Healthy になりませんでした。
ArgoCD がそもそも起動しなかったのでアプリケーションのデプロイが実行できません。
この不具合に対して以下のコマンドを直接実行して ArgoCD のロールバックを試みました。[1]
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.11.0/manifests/install.yaml
上記対応により ArgoCD はロールバックされヘルスチェックが通過しました。
また、アプリケーションのデプロイも無事実行できるようになりました。
この操作により ArgoCD は差分がある状態へとなりますが、修正が行われるまで v2.11.1 の適用は控えていました。
よかった点
本事象が本番環境で起こらなかった（起こらない状況になっていた）ことがよかったです。
ArgoCD は GitOps ツールであるので壊れたとしてもアプリケーションコードに対してなにも影響は発生しないかと思います。
（今回 ArgoCD の不具合が発生した環境もアプリケーションは問題なく稼働し続けていました。）
それでも本番環境で問題が発生するのは焦るのでそれを防げていたことはよかったです。
また、ArgoCD をすぐにコマンドを用いてロールバック対応できた点もよかったです。
アプリケーション自体に問題がなかったとはいえ放置することなく稼働状態に戻すことができました。
これからを考える
stable というバージョン指定で ArgoCD を管理していますが、壊れることもあるんだなと学びを得ました。
壊れたことで困りはしましたが、今回の経験を通してコマンドを使ってロールバックができるとわかったので運用としてはいまのままでよいのかなと考えています。
直接 kubectl apply コマンドを実行してロールバックすることに抵抗感がある場合はマニフェストで直接バージョン指定する方がよいかと思います。
ただし、アプリケーションの管理同様 ArgoCD マニフェストのバージョンを更新する仕組みを整えてあげる必要があります。
おわりに
すぐに復旧することはできましたが、ArgoCD をどうやって治せばよいのかについてアイデアは出せなかったです。
これが私のいまの力量です。
これからも精進していきます。
-
kubectlコマンドを直接実行する際は接続先コンテキストの設定に気をつけてください。 ↩︎
Discussion