KubernetesをAnsibleで飼いならす：kubectl卒業から「宣言的自動化」の深淵へ
こんにちは。クラウドインフラを愛するエンジニアの皆さん。
日々の運用で、こんな経験はありませんか？
「`kubectl apply -f manifest.yaml` を叩くのはいいけれど、結局どのリソースが適用済みで、どれが未適用なのか管理しきれない…」「複数のクラスタにまたがる設定変更を、ヒューマンエラーなしで確実に行いたい」。
もしあなたが「kubectlコマンドの連打」という泥沼から抜け出したいなら、AnsibleによるKubernetesリソース管理は、間違いなくあなたの強力な武器になります。今日は、Ansibleの`kubernetes.core`コレクションを使い、冪等（べきとう）性を担保しながらK8sを「制御」する、プロフェッショナルの手法を伝授します。
—
なぜ「kubectl」ではなく「Ansible」なのか？
`kubectl`は対話的なツールであり、その場限りの操作には最適です。しかし、インフラの本質は「あるべき姿（Desired State）」を定義し、それを維持することにあります。
Ansibleを介することで、以下の恩恵が手に入ります。
1. 冪等性の担保: すでに適用済みのリソースは無視し、差分だけを適用する。
2. 構成管理の一元化: OS設定、ミドルウェア、そしてK8sリソースまでを一つのPlaybookで繋げる。
3. ワークフローの統合: 例えば「DBを移行して、その直後にK8sのDeploymentを更新する」といった、環境を跨いだ依存関係を一つのタスクとして記述できる。
—
1. 準備：最強の相棒「kubernetes.core」をインストールする
まずは環境を整えましょう。AnsibleがK8sを理解するためには、公式コレクションが必要です。
必要なコレクションをインストール
ansible-galaxy collection install kubernetes.core
依存するPythonライブラリ（kubernetesクライアント）を忘れずに
pip install kubernetes
ここで重要なのは、実行環境の認証情報です。Ansibleは標準で `~/.kube/config` を読みに行きます。もしCI/CDパイプラインや別サーバーから操作するなら、環境変数 `K8S_AUTH_KUBECONFIG` を指定するか、Playbook内で `kubeconfig` パラメータを明示的に渡すのが定石です。
—
2. Hello World：Nginxを「宣言」する
まずは、最もシンプルなNginxのPodをデプロイしてみましょう。以下のPlaybookを見てください。
—
- name: Kubernetesリソース管理の実験
hosts: localhost
connection: local
tasks:
- name: NginxのDeploymentを作成（または更新）
kubernetes.core.k8s:
state: present
definition:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
このコードの「賢さ」に注目してください
- `state: present`: これが冪等性の魔法です。「存在していなければ作る、存在していれば何もしない（あるいは差分があれば修正する）」。
- `definition`: ここにマニフェストを直接記述できます。これにより、YAMLファイルが散乱するのを防ぎ、Playbook内に設定を封じ込めることができます。
—
3. プロの現場で差がつく「極限の知見」
初心者から脱却し、現場で信頼されるSREになるためのポイントを3つ教えます。
① 既存のYAMLファイルをそのまま読み込む
毎回Playbookに定義を書くのは非効率です。大規模な構成では、テンプレート機能と組み合わせましょう。
- name: 外部のYAMLファイルを適用
kubernetes.core.k8s:
state: present
src: ./manifests/production-app.yaml # ファイルを指定するだけ
② 「Wait」を活用してデプロイの健全性を保証する
単にリソースを投入するだけでは不十分です。「Podが正常に起動するまで待つ」のがプロの流儀です。
- name: Deploymentのロールアウト完了を待機
kubernetes.core.k8s_info:
kind: Deployment
name: nginx-deployment
namespace: default
register: deployment_info
until: deployment_info.resources[0].status.readyReplicas == 2
retries: 10
delay: 5
③ 差分管理（Diff）を有効活用する
Ansibleを実行する際、`–diff` オプションを付けてみてください。何が変わるのか、どの行が修正されるのかを事前に確認できます。これが、本番環境で「震えない」ための最大の防御策です。
—
まとめ：自動化の先にある景色
AnsibleでK8sを操作することは、単なるツールの置き換えではありません。「インフラ全体をコードとして定義し、その状態をAnsibleに担保させる」という、堅牢な運用基盤への第一歩です。
まずは今日紹介した簡単なDeploymentの作成から始めてみてください。それができれば、次はConfigMapの動的生成や、Helmチャートのデプロイ自動化へと、あなたの管理術はどこまでも拡張できます。
毎日の「手動作業」から解放され、より本質的なアーキテクチャ設計に時間を割けるようになること。それこそが、この手法をマスターする最大の報酬です。
さあ、次はどのリソースを自動化しますか？応援しています。