Flux は、Kubernetes のイベントを通じて、自分が行ったことを報告し、notification controller がそれらをアラートに変え、webhook も受信します。このガイドでは、2 つのことを設定します。何かが失敗または成功したときにチャットツールへ送られる送信アラートと、次のポーリングを待つ代わりに、push の直後に Flux に調整させる受信 webhook です。例は Slack ですが、同じオブジェクトが Microsoft Teams、PagerDuty、Discord、汎用の webhook などで機能し、GitHub や GitLab のような Git プロバイダーでは、commit のステータスにも使えます。

Slack にアラートを送る

3 つのオブジェクトが関わります。webhook のアドレスを持つ Secret、どこに送るかを記述する Provider、何を送るかを記述する Alert です。

Secret を作成します（キーは address である必要があります）。

kubectl create secret generic slack-url \
  --namespace=flux-system \
  --from-literal=address=https://hooks.slack.com/services/XXX/YYY/ZZZ

apps/notifications/provider.yaml:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Provider
metadata:
  name: slack
  namespace: flux-system
spec:
  type: slack
  channel: deployments
  secretRef:
    name: slack-url

apps/notifications/alert.yaml:

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Alert
metadata:
  name: on-call
  namespace: flux-system
spec:
  providerRef:
    name: slack
  eventSeverity: error
  eventSources:
    - kind: GitRepository
      name: "*"
    - kind: Kustomization
      name: "*"
    - kind: HelmRelease
      name: "*"
      namespace: podinfo

重要なポイントは次のとおりです。

• providerRef は宛先を選びます。
• eventSeverity は info（成功した適用を含むすべて）または error です。静かなオンコールのチャンネルには error、デプロイのログには info を使います。
• eventSources は、どのオブジェクトを監視するかを列挙します。"*" という名前は、namespace 内のその種類のすべてのオブジェクトに一致するため、他の namespace を監視するには namespace: を使います。

通知の API バージョンは変更されつつあります。v1beta2 は Flux 2.9 で削除されたため、Flux 2.9 を実行している場合は、示したように v1beta3 を使ってください。v1 の API は Flux 2.10 で計画されています。クラスターが何をサポートしているかを、次のコマンドで確認します。

kubectl get crd alerts.notification.toolkit.fluxcd.io \
  -o jsonpath='{.spec.versions[*].name}'; echo

これらのファイルを commit すると、Kustomization で何かが失敗したときに、オブジェクト、リビジョン、エラーを含むメッセージがチャンネルに現れます。Git でマニフェストのパスを意図的に壊して試してください。

commit のステータスを GitHub に報告する

2 つ目の Provider は、デプロイの結果を commit のステータスとして投稿でき、プルリクエストや commit に、Flux がそれを適用したかどうかが表示されます。

apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Provider
metadata:
  name: github-status
  namespace: flux-system
spec:
  type: github
  address: https://github.com/your-org/fleet-infra
  secretRef:
    name: github-token   # "token" キーを持つ Secret

Kustomization を source として列挙する Alert と組み合わせます。トークンには、commit のステータスを書き込む権限が必要です。

即時の同期のために webhook を受信する

デフォルトでは、Flux は GitRepository の間隔で Git をポーリングします。Receiver は、Git ホストからの webhook を受け付け、すぐに調整をトリガーします。そのため、ポーリングの間隔を長くしても、ほぼ即座のデプロイが得られます。

共有の秘密のトークンを作成します（キーは token である必要があります）。

TOKEN=$(head -c 12 /dev/urandom | shasum | cut -d ' ' -f1)
echo $TOKEN
kubectl create secret generic webhook-token \
  --namespace=flux-system --from-literal=token=$TOKEN

次に Receiver を、安定版の v1 API で作成します。

apiVersion: notification.toolkit.fluxcd.io/v1
kind: Receiver
metadata:
  name: github-receiver
  namespace: flux-system
spec:
  type: github
  events:
    - ping
    - push
  secretRef:
    name: webhook-token
  resources:
    - apiVersion: source.toolkit.fluxcd.io/v1
      kind: GitRepository
      name: flux-system

適用したら、Flux が生成したパスを尋ねます。

flux get receivers

パスは /hook/<hash> のような形をしています。notification controller は、flux-system の webhook-receiver という名前の Service を通じてそれを公開しており、Ingress や LoadBalancer でインターネットに公開します。次に、リポジトリの設定で、その URL、コンテンツタイプ application/json、シークレットとしてのトークン、push イベントを持つ webhook を追加します。これで push は、GitRepository と、それに依存するすべてのものの調整をトリガーします。Flux 2.9 は、OIDC トークンを提示できるプラットフォーム向けに、共有シークレットを必要としない、OIDC で保護された汎用の Receiver もサポートしています。

トラブルシューティング

• メッセージが届かない：kubectl describe alert on-call -n flux-system と、flux logs --level=error でコントローラーのログを確認し、Secret のキーが address という名前であることを確認します。
• webhook がトリガーされない：Git ホストの配信ログを見ます。404 は通常、パスが間違っていることを、401 や 403 は、トークンが一致しないことを意味します。
• ノイズが多すぎる：eventSeverity を絞り込み、"*" の代わりに、特定の eventSources を列挙します。