# สร้าง Kubernetes ไว้ใช้เอง โดยมี "AI DevOps VM" เครื่องเดียวเป็นศูนย์บัญชาการ > ออกแบบระบบที่คุณสั่งงานจาก VM เครื่องเดียวด้วย CLI แล้ว AI ทำหน้าที่ติดตั้ง ตรวจสอบ แก้ปัญหา จูน และซัพพอร์ตทั้ง cluster แทนทีม DevOps ทั้งทีม — โดยยังคุมความเสี่ยงและ audit ได้ในระดับที่เอาไปใช้กับงานจริงได้ --- ## 1. โจทย์และแนวคิดหลัก โจทย์คือ **"ศูนย์บัญชาการเครื่องเดียว"** — มี VM หนึ่งเครื่อง (เรียกว่า `ai-ops-00`) ที่: - ติดตั้ง Kubernetes ไปทุกเครื่องที่เกี่ยวข้อง - ติดตั้งซอฟต์แวร์บน cluster (Jenkins, registry, database, monitoring, ฯลฯ) - ตรวจสอบ วิเคราะห์ แก้ปัญหา จูน หลังขึ้นงาน - ทั้งหมดสั่งผ่าน CLI + AI agent ไม่ต้องมีทีม DevOps ปัญหาที่คนส่วนใหญ่ทำพลาด คือปล่อยให้ AI `ssh` เข้าเครื่องแล้วรันคำสั่งมั่ว ๆ ผลลัพธ์คือ **config drift** — สามเดือนผ่านไปไม่มีใครรู้ว่าเครื่องไหนมีอะไรอยู่บ้าง แก้อะไรไปแล้ว และย้อนกลับไม่ได้ ดังนั้นหลักการออกแบบทั้งหมดในบทความนี้วางอยู่บนกฎ 5 ข้อ: | # | หลักการ | เหตุผล | |---|---|---| | 1 | **Declarative ก่อนเสมอ** | AI แก้ YAML ใน Git ไม่ใช่รัน `kubectl apply` เอง — ย้อนกลับได้ ตรวจสอบได้ | | 2 | **Git คือแหล่งความจริงเดียว** | ถ้า Git ไม่มี = ไม่มีอยู่จริง; cluster ต้อง converge เข้าหา Git เสมอ | | 3 | **AI VM อยู่นอก cluster** | cluster ล่ม ศูนย์บัญชาการต้องยังอยู่ ไม่งั้นซ่อมไม่ได้ | | 4 | **สิทธิ์แบ่งเป็นวง (Ring)** | อ่านได้เสรี / เขียนผ่าน PR / ทำลายต้องมนุษย์อนุมัติ | | 5 | **AI VM เป็น stateless** | state ทั้งหมดอยู่ใน Git + Vault; เครื่องพังสร้างใหม่ได้ใน 15 นาที | กฎข้อ 1 และ 2 คือหัวใจ เพราะมันเปลี่ยนบทบาท AI จาก "คนกดคำสั่ง" เป็น **"คนเขียน desired state"** ซึ่งเป็นงานที่ LLM ทำได้ดีกว่ามาก และผิดพลาดแล้วกู้คืนง่ายกว่ามาก --- ## 2. สถาปัตยกรรมภาพรวม ```mermaid flowchart TB Human([คุณ - สั่งงานภาษาไทยผ่าน CLI]) subgraph CMD["ศูนย์บัญชาการ ai-ops-00 (อยู่นอก cluster)"] AGENT[/"AI Agent Layer
Claude Code / Kimi CLI + MCP"/] TOOLS[["Tool Belt
kubectl helm talosctl ansible
argocd promtool logcli trivy"]] BOOK[("Runbooks + Skills + CLAUDE.md
/opt/ops")] AGENT --- TOOLS AGENT --- BOOK end GIT[("Git Repo — Single Source of Truth
infra + platform + apps + policy")] subgraph MGMT["Management Cluster"] ARGO[["Argo CD — reconcile engine"]] CAPI[["Cluster API — provision cluster/node"]] OBS[("Prometheus / Loki / Grafana / Alertmanager")] end subgraph WL["Workload Clusters"] PROD[Prod] STG[Staging] DEV[Dev] end NOTE1>"AI เขียนได้แค่ทาง Git เท่านั้น
เส้นทึบ = write path"] NOTE2>"เส้นประ = read-only / observe"] Human --> AGENT AGENT --> GIT GIT --> ARGO ARGO ==> PROD ARGO ==> STG ARGO ==> DEV CAPI -.-> WL PROD -.-> OBS STG -.-> OBS DEV -.-> OBS OBS -.-> AGENT WL -.-> AGENT CMD -.- NOTE1 CMD -.- NOTE2 ``` จุดสำคัญของภาพนี้: - **AI ไม่เคยเขียนลง cluster โดยตรงในทางปกติ** — มันเขียนลง Git แล้ว Argo CD เป็นคนเอาไป apply - **AI อ่านได้ทุกอย่าง** — kubeconfig แบบ read-only + query Prometheus/Loki ได้เสรี เพราะการอ่านไม่ทำให้พัง - **Management cluster แยกจาก workload** — ถ้า prod ล่ม ตัวควบคุมยังอยู่ --- ## 3. เครื่อง `ai-ops-00` — สเปกและ Stack ### 3.1 สเปกเครื่อง | รายการ | ค่าแนะนำ | หมายเหตุ | |---|---|---| | vCPU | 4–8 | build/test บางอย่างรันที่นี่ | | RAM | 16–32 GB | agent + local model cache + kubectl tree ใหญ่ ๆ | | Disk | 200 GB SSD | Git clone หลาย repo + image cache + audit log | | OS | Ubuntu 24.04 LTS หรือ RHEL 9 | เลือกให้ตรงกับ baseline security ขององค์กร | | Network | อยู่ management VLAN, เข้าถึงทุก node ได้ | ต้องออกเน็ตได้ (API ของ AI + pull artifact) | | Snapshot | daily | เป็น VM ที่ควร snapshot ไว้แม้จะ stateless | ### 3.2 Stack ที่ต้องมี ``` ai-ops-00 ├── AI Layer │ ├── claude-code # orchestrator หลัก │ ├── kimi-cli # worker สำหรับงานยาว/ถูก │ └── MCP servers # kubernetes, prometheus, loki, git, filesystem ├── Infrastructure │ ├── opentofu / terraform # provision VM (Proxmox / vSphere / Hetzner) │ ├── ansible # config เครื่องที่ไม่ใช่ immutable OS │ └── talosctl หรือ rke2 # bootstrap kubernetes ├── Cluster │ ├── kubectl + krew # neat, tree, who-can, view-secret │ ├── helm + kustomize + helmfile │ ├── k9s / kubectx / kubens / stern │ └── cilium + hubble # troubleshoot network ระดับ eBPF ├── GitOps │ ├── argocd │ └── gh / glab # เปิด PR อัตโนมัติ ├── Observability │ ├── promtool # query + validate rule │ ├── logcli # query Loki จาก CLI │ └── kubectl-trace / pprof ├── Security & Validation │ ├── kubeconform + kube-linter │ ├── kyverno-cli │ ├── trivy + kubescape │ └── sops + age # เข้ารหัส secret ใน Git └── /opt/ops ├── CLAUDE.md # ธรรมนูญของ AI ├── runbooks/*.md # วิธีแก้ปัญหาที่มนุษย์อ่านได้ด้วย ├── skills/ # Claude Code skills เฉพาะทาง └── policies/ # Kyverno / OPA ``` ### 3.3 สคริปต์ bootstrap เครื่อง ```bash #!/usr/bin/env bash # bootstrap-ai-ops.sh — provision the AI DevOps control node from scratch # Target: Ubuntu 24.04 LTS. Idempotent, safe to re-run. set -euo pipefail OPS_HOME=/opt/ops BIN=/usr/local/bin log() { echo -e "\n>>> $*\n"; } log "Base packages" sudo apt-get update -qq sudo apt-get install -y curl wget git jq yq unzip make gnupg \ python3-pip pipx asciinema age log "kubectl + krew plugins" curl -fsSL "https://dl.k8s.io/release/$(curl -sL https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" \ -o /tmp/kubectl && sudo install -m0755 /tmp/kubectl $BIN/kubectl ( set -x; cd "$(mktemp -d)" curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/krew-linux_amd64.tar.gz" tar zxvf krew-linux_amd64.tar.gz && ./krew-linux_amd64 install krew ) export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH" kubectl krew install neat tree who-can view-secret ctx ns log "Helm, Kustomize, Argo CD CLI" curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash curl -fsSL "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash sudo mv kustomize $BIN/ curl -fsSL -o /tmp/argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64 sudo install -m0755 /tmp/argocd $BIN/argocd log "Cluster bootstrap tooling (Talos track)" curl -fsSL https://talos.dev/install | sh log "Observability + security CLI" curl -fsSL https://github.com/aquasecurity/trivy/releases/latest/download/trivy_Linux-64bit.tar.gz \ | sudo tar xz -C $BIN trivy pipx install kube-linter || true curl -fsSL https://github.com/yannh/kubeconform/releases/latest/download/kubeconform-linux-amd64.tar.gz \ | sudo tar xz -C $BIN kubeconform log "SOPS for encrypted secrets in Git" curl -fsSL -o /tmp/sops https://github.com/getsops/sops/releases/latest/download/sops-linux-amd64 sudo install -m0755 /tmp/sops $BIN/sops mkdir -p ~/.config/sops/age [ -f ~/.config/sops/age/keys.txt ] || age-keygen -o ~/.config/sops/age/keys.txt log "Ops workspace" sudo mkdir -p $OPS_HOME/{runbooks,skills,policies,audit} sudo chown -R "$USER:$USER" $OPS_HOME log "Shell session recording — every AI action is replayable" cat <<'EOF' | sudo tee /etc/profile.d/99-audit-record.sh >/dev/null # Record all interactive shell sessions for audit replay if [ -z "$ASCIINEMA_REC" ] && [ -t 0 ] && [[ "$-" == *i* ]]; then export ASCIINEMA_REC=1 exec asciinema rec -q --command "$SHELL -l" \ "/opt/ops/audit/$(date +%Y%m%d-%H%M%S)-$USER.cast" fi EOF log "Done. Next: clone the gitops repo into $OPS_HOME and run 'claude' inside it." ``` ### 3.4 MCP servers — เปลี่ยนจาก "shell มั่ว" เป็น "เครื่องมือมีขอบเขต" จุดนี้คือสิ่งที่ยกระดับจาก "AI ที่รันคำสั่ง" เป็น "AI ที่มี tool จริง" — เพราะ MCP บังคับ schema และจำกัดขอบเขตได้ ```json { "mcpServers": { "k8s-readonly": { "command": "kubernetes-mcp-server", "args": ["--read-only", "--kubeconfig", "/opt/ops/kubeconfig/ai-readonly.yaml"] }, "prometheus": { "command": "prometheus-mcp", "args": ["--url", "https://prom.mgmt.internal"] }, "loki": { "command": "loki-mcp", "args": ["--url", "https://loki.mgmt.internal"] }, "gitops": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/opt/ops/gitops"] } } } ``` --- ## 4. เลือก Kubernetes distro ให้เหมาะกับ AI-driven ops การเลือก distro มีผลกับความสำเร็จของแนวทางนี้มาก เพราะ **distro ที่ declarative มากกว่า = AI พังน้อยกว่า** | | Talos Linux | RKE2 | k3s | kubeadm + RHEL | |---|---|---|---|---| | ปรัชญา | Immutable, API-only, ไม่มี SSH/shell | Hardened k8s บน OS ปกติ | Lightweight single binary | Vanilla สุด | | Config drift | เป็นศูนย์ (แก้ไม่ได้นอกจากผ่าน machineconfig) | ปานกลาง | ปานกลาง | สูง | | เหมาะกับ AI | ★★★★★ | ★★★★ | ★★★★ | ★★ | | CIS hardened by default | ✔ | ✔ | บางส่วน | ต้องทำเอง | | FIPS / SELinux / RHEL support | ✘ | ✔ | จำกัด | ✔ | | ลง agent องค์กร (EDR/backup) | ทำไม่ได้ | ทำได้ | ทำได้ | ทำได้ | | Learning curve | สูงตอนแรก แต่หลังจากนั้นง่ายมาก | ปานกลาง | ต่ำ | สูงตลอด | | upgrade | `talosctl upgrade` ทั้ง OS+k8s ในคำสั่งเดียว | ดี | ดี | ต้องทำเอง | **คำแนะนำ:** - **Greenfield / คุมเองทั้งหมด → Talos Linux** เพราะไม่มี shell ให้ใครไปแก้มั่ว ทุกอย่างต้องผ่าน `machineconfig` YAML = ตรงกับปรัชญา declarative 100% และ AI จะไม่มีทางทำ drift ได้เลยแม้จะพยายาม - **องค์กรที่มี security baseline บังคับ RHEL / ต้องลง EDR / ต้อง FIPS → RKE2** เพราะรันบน RHEL 9 ได้ ผ่าน CIS benchmark ได้ตั้งแต่ default และทีม security ตรวจได้ด้วยเครื่องมือเดิม - **Lab / edge / เครื่องน้อย → k3s** - **kubeadm** เลือกเมื่อจำเป็นจริง ๆ เท่านั้น เพราะงาน day-2 หนักที่สุด ตัวอย่าง machineconfig ของ Talos ที่ AI จะเป็นคนแก้: ```yaml # talos/nodes/worker-pool-general.yaml # Worker pool for general workloads. AI edits this file, never the running node. version: v1alpha1 machine: type: worker kubelet: extraArgs: rotate-server-certificates: "true" nodeLabels: node-pool: general topology.kubernetes.io/zone: dc1-rack3 sysctls: vm.max_map_count: "262144" # required by Elasticsearch / OpenSearch install: disk: /dev/sda image: ghcr.io/siderolabs/installer:v1.9.2 cluster: controlPlane: endpoint: https://k8s-vip.internal:6443 ``` --- ## 5. Layer ของ Cluster ```mermaid flowchart TB subgraph L4["Layer 4 — Application"] JEN[Jenkins Controller + ephemeral Agent Pods] HB[Harbor Registry] APP[Business Apps] DB[(StatefulSet: PostgreSQL / Redis / Kafka)] end subgraph L3["Layer 3 — Delivery & Governance"] ARGO[Argo CD] KYV[Kyverno — admission policy] VEL[Velero — backup/restore] ESO[External Secrets Operator] end subgraph L2["Layer 2 — Platform Services"] ING[Ingress-NGINX หรือ Gateway API] CM[cert-manager] EDNS[external-dns] KPS[kube-prometheus-stack] LOKI[Loki + Promtail] TEMPO[Tempo — tracing] end subgraph L1["Layer 1 — Cluster Core"] CORE[kube-apiserver / etcd / scheduler / controller-manager] CNI[Cilium CNI + Hubble] CSI[Longhorn หรือ Rook-Ceph] LBIP[MetalLB + kube-vip] DNS[CoreDNS] end subgraph L0["Layer 0 — Infrastructure"] OS[Talos Linux หรือ RHEL9 + RKE2] VMH[Proxmox / vSphere / Bare Metal] NET[VLAN / Firewall / DNS / NTP] end L0 --> L1 L1 --> L2 L2 --> L3 L3 --> L4 NB>"ทุก Layer ตั้งแต่ 1 ขึ้นไป ติดตั้งด้วย Argo CD
Layer 0 ติดตั้งด้วย OpenTofu + talosctl/ansible"] L0 -.- NB ``` ### เหตุผลของตัวเลือกสำคัญ - **Cilium** — ไม่ใช่แค่ CNI แต่ให้ `hubble observe` ที่ AI ใช้ตอบคำถามอย่าง "pod A ต่อ pod B ไม่ได้ ติดที่ไหน" ได้แม่นยำ ซึ่ง CNI อื่นตอบไม่ได้ นี่คือความต่างมหาศาลตอน troubleshoot - **Longhorn** เริ่มต้นง่าย มี UI, snapshot, backup ไป S3 ได้ / **Rook-Ceph** เมื่อโตเกิน ~20 node หรือต้องการ block+object+file ในตัวเดียว - **Gateway API** ถ้าเริ่มใหม่ปีนี้ ควรเริ่มที่ Gateway API เลย เพราะ Ingress อยู่ในโหมด maintenance - **External Secrets Operator + OpenBao/Vault** — secret ไม่ควรอยู่ใน Git แม้จะเข้ารหัสแล้ว ถ้าองค์กรมี Vault อยู่แล้วให้ต่อเลย; ถ้ายัง เริ่มด้วย SOPS+age ก่อนได้ --- ## 6. โครงสร้าง Git Repo — สมองของระบบ ``` gitops/ ├── CLAUDE.md # ธรรมนูญที่ AI ต้องอ่านก่อนทำงานทุกครั้ง ├── README.md ├── infrastructure/ │ ├── tofu/ # OpenTofu: VM, network, DNS, LB │ │ ├── proxmox-nodes/ │ │ └── dns-records/ │ └── talos/ │ ├── controlplane.yaml │ ├── worker-pool-general.yaml │ └── worker-pool-memory.yaml ├── clusters/ │ ├── mgmt/ │ │ ├── bootstrap/ # Argo CD self-manage │ │ └── apps.yaml # ApplicationSet ชี้ไปที่ platform/ │ ├── prod/ │ ├── staging/ │ └── dev/ ├── platform/ # Layer 1-3 ทุกตัว │ ├── cilium/ │ ├── cert-manager/ │ ├── longhorn/ │ ├── kube-prometheus-stack/ │ ├── loki/ │ ├── kyverno/ │ ├── velero/ │ └── argocd/ ├── apps/ │ ├── base/ │ │ ├── jenkins/ │ │ ├── harbor/ │ │ └── payment-api/ │ └── overlays/ │ ├── dev/ │ ├── staging/ │ └── prod/ ├── policies/ # Kyverno ClusterPolicy │ ├── require-resource-limits.yaml │ ├── disallow-latest-tag.yaml │ └── restrict-namespace-deletion.yaml └── ops/ ├── runbooks/ │ ├── pod-crashloop.md │ ├── node-notready.md │ ├── etcd-degraded.md │ ├── certificate-expiry.md │ ├── pvc-full.md │ └── add-worker-node.md ├── skills/ │ ├── diagnose-workload/SKILL.md │ ├── scale-node-pool/SKILL.md │ └── onboard-new-app/SKILL.md └── kubeconfig/ ├── ai-readonly.yaml └── breakglass.yaml.enc # เข้ารหัสด้วย age, มนุษย์ถอดเท่านั้น ``` **สาระสำคัญคือโฟลเดอร์ `ops/runbooks/`** — เขียนเป็น markdown ที่ทั้ง AI และมนุษย์อ่านได้ ตัวอย่าง: ```markdown # Runbook: Pod อยู่ในสถานะ CrashLoopBackOff ## เกณฑ์ตัดสิน 1. ดู `lastState.terminated.reason` - `OOMKilled` → ไป §A - `Error` exit 1 → ไป §B - `Completed` → job ที่ตั้ง restartPolicy ผิด → ไป §C ## §A OOMKilled 1. `kubectl top pod -n --containers` 2. PromQL: `max_over_time(container_memory_working_set_bytes{pod=""}[7d])` 3. ถ้า peak > 80% ของ limit → เสนอ PR ขึ้น limit เป็น peak x 1.5 ปัดขึ้นหลัก 256Mi 4. ถ้า memory โตเป็นเส้นตรงตลอด 7 วัน → สงสัย memory leak ห้ามขึ้น limit อย่างเดียว ต้องแจ้งเจ้าของแอปด้วย ## ข้อห้าม - ห้าม `kubectl delete pod` เพื่อ "ให้มันหาย" โดยไม่หาสาเหตุก่อน - ห้ามแก้ limit ตรงบน cluster ต้องผ่าน PR เท่านั้น ``` Runbook ที่ดีทำให้คำตอบของ AI นิ่งและซ้ำได้ แทนที่จะเดาใหม่ทุกครั้ง --- ## 7. Guardrails — ระบบสิทธิ์ 3 วง นี่คือส่วนที่ทำให้แนวทางนี้ปลอดภัยพอจะใช้กับงานจริง ```mermaid flowchart TB REQ{{คำสั่งจากผู้ใช้}} --> CLS{จำแนกประเภทการกระทำ} CLS -->|อ่านอย่างเดียว| R0 CLS -->|เปลี่ยน desired state| R1 CLS -->|ทำลาย / เร่งด่วน| R2 subgraph G0["Ring 0 — Read Only (อนุญาตอัตโนมัติ)"] R0[/"get / describe / logs / top / events
PromQL, logcli, hubble observe, argocd app get"/] end subgraph G1["Ring 1 — GitOps Write (commit อัตโนมัติ, merge มี gate)"] R1[/"แก้ manifest → commit → เปิด PR"/] CI[["CI Gate: kubeconform + kube-linter
kyverno-cli test + trivy + argocd diff"]] MG{ผ่านทุก gate?} R1 --> CI --> MG end subgraph G2["Ring 2 — Break Glass (ต้องมนุษย์อนุมัติ)"] R2[/"delete, drain, cordon, scale prod
etcd restore, rotate cert, restart node"/] AP{มนุษย์กด approve?} SOPS[("ถอดรหัส breakglass kubeconfig ด้วย age
cert อายุ 1 ชั่วโมง")] R2 --> AP AP -->|yes| SOPS end R0 --> ANS[/รายงานผลให้ผู้ใช้/] MG -->|yes| SYNC[Argo CD sync เข้า cluster] MG -->|no| ANS AP -->|no| ANS SOPS --> DIRECT[รันตรงเข้า cluster] AUD[("Audit: git log + k8s audit log
+ asciinema replay")] SYNC -.-> AUD DIRECT -.-> AUD R0 -.-> AUD ANS -.-> AUD ``` ### 7.1 RBAC สำหรับ AI (Ring 0) ```yaml # platform/rbac/ai-readonly.yaml # Read-only identity for the AI agent. No secrets, no exec, no port-forward. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: ai-ops-readonly rules: - apiGroups: ["", "apps", "batch", "networking.k8s.io", "policy", "autoscaling", "storage.k8s.io", "apiextensions.k8s.io"] resources: ["*"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["pods/log"] verbs: ["get", "list"] - apiGroups: ["metrics.k8s.io"] resources: ["*"] verbs: ["get", "list"] --- # Explicitly deny the dangerous read paths. Secrets contain credentials; # exec and port-forward are write operations in disguise. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: ai-ops-readonly-exclusions rules: [] # documented as a deliberate empty set — see note below ``` > หมายเหตุ: Kubernetes RBAC เป็น allow-list ล้วน ไม่มี deny rule ดังนั้นการ "ห้าม" ทำได้โดย **ไม่ใส่** `secrets`, `pods/exec`, `pods/portforward` เข้าไปใน rule ข้างบน แล้วบังคับซ้ำอีกชั้นด้วย Kyverno + admission webhook ที่ตรวจ `user` ของ request ### 7.2 Policy บังคับที่ admission (Ring 1 gate) ```yaml # policies/restrict-namespace-deletion.yaml # Even if a request somehow reaches the API server with the AI identity, # the admission layer stops destructive verbs on protected namespaces. apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: protect-critical-namespaces spec: validationFailureAction: Enforce background: false rules: - name: block-delete-by-ai-identity match: any: - resources: kinds: ["Namespace", "PersistentVolumeClaim", "StatefulSet"] operations: ["DELETE"] exclude: any: - subjects: - kind: User name: "breakglass-operator" validate: message: >- Destructive operations on this resource require the break-glass identity with explicit human approval. deny: {} ``` ### 7.3 Break-glass (Ring 2) ```bash # ops/scripts/breakglass.sh — issue a 1-hour admin credential, human-gated set -euo pipefail read -rp "เหตุผลที่ต้องใช้ break-glass: " REASON read -rp "พิมพ์ 'CONFIRM' เพื่อยืนยัน: " CONFIRM [[ "$CONFIRM" == "CONFIRM" ]] || { echo "ยกเลิก"; exit 1; } # Log the intent before the credential exists echo "$(date -Is)|$USER|$REASON" >> /opt/ops/audit/breakglass.log # Decrypt with the operator's age key — the AI has no access to this key sops -d /opt/ops/kubeconfig/breakglass.yaml.enc > /tmp/bg.yaml chmod 600 /tmp/bg.yaml export KUBECONFIG=/tmp/bg.yaml echo "Break-glass session active for 60 minutes." # Auto-revoke: the embedded client cert has a 1h NotAfter ( sleep 3600; shred -u /tmp/bg.yaml ) & ``` --- ## 8. `CLAUDE.md` — ธรรมนูญของ AI ไฟล์นี้อยู่ที่ root ของ gitops repo และเป็นสิ่งแรกที่ AI อ่าน มันสำคัญกว่าที่หลายคนคิด เพราะมันคือที่เดียวที่คุณกำหนด "นิสัย" ของ DevOps คนนี้ ```markdown # ธรรมนูญปฏิบัติการ — ai-ops-00 คุณคือ DevOps engineer ประจำ cluster นี้ รายงานผลเป็นภาษาไทย comment ในโค้ดเขียนภาษาอังกฤษ ## ลำดับการทำงานบังคับ 1. อ่าน `ops/runbooks/` หา runbook ที่ตรงกับอาการก่อนเสมอ ถ้าไม่มี ให้บอกว่าไม่มี แล้วเสนอสร้างใหม่หลังแก้เสร็จ 2. รวบรวมหลักฐานก่อนสรุป — อย่างน้อย 2 แหล่ง (k8s event + metric หรือ log) 3. ระบุสาเหตุที่แน่ใจ กับ สมมติฐานที่ยังไม่ยืนยัน แยกกันชัดเจน 4. เสนอทางแก้อย่างน้อย 2 ทาง พร้อมผลกระทบและเวลาที่ใช้ 5. รอผู้ใช้เลือก ห้ามลงมือเอง ## ห้ามเด็ดขาด - ห้ามรัน kubectl apply / edit / patch / delete / scale ตรงเข้า cluster ใด ๆ ทุกการเปลี่ยนแปลงต้องเป็น commit ใน repo นี้แล้วเปิด PR - ห้ามใช้ kubeconfig อื่นนอกจาก ops/kubeconfig/ai-readonly.yaml - ห้ามอ่านหรือ decode Secret ทุกกรณี ถ้าต้องรู้ค่า ให้บอกผู้ใช้ไปอ่านเอง - ห้าม commit ค่า credential ลง Git แม้จะเข้ารหัสแล้ว ให้ใช้ ExternalSecret - ห้ามแตะ namespace: kube-system, argocd, longhorn-system โดยไม่ถาม - ห้าม force push, ห้าม merge PR เอง ## ก่อนเปิด PR ทุกครั้งต้องรัน ```bash kubeconform -strict -summary kube-linter lint kyverno apply policies/ --resource argocd app diff --local ``` แล้วแปะผลลัพธ์ทั้ง 4 ลงใน PR description ## รูปแบบ PR - branch: `ai/-` - title: `[ai-ops] <สรุปสั้น>` - body ต้องมี: อาการ / หลักฐาน / สาเหตุ / สิ่งที่แก้ / วิธี rollback / วิธี verify - ทุก commit ใส่ `Co-authored-by: ai-ops ` ## เมื่อไม่แน่ใจ พูดว่าไม่แน่ใจ อย่าเดา — cluster นี้มีของจริงรันอยู่ ``` --- ## 9. รองรับซอฟต์แวร์อะไรก็ได้ — กรณี Jenkins โจทย์บอกว่าต้องรองรับ Jenkins และซอฟต์แวร์อื่น ๆ หลักการคือ **ทุกซอฟต์แวร์ต้องเข้ามาด้วย pattern เดียวกัน** ไม่มีข้อยกเว้น: ``` Helm chart / Kustomize base → overlay ต่อ env → Argo CD Application → PR → sync ``` Jenkins มีข้อดีคือรองรับ **JCasC (Jenkins Configuration as Code)** ซึ่งแปลว่า config ของ Jenkins เองก็เป็น YAML ใน Git ได้ = AI จัดการได้เต็มที่ ```yaml # apps/base/jenkins/values.yaml # Jenkins with JCasC + dynamic k8s agents. No manual UI configuration allowed: # anything configured through the UI is lost on restart — that is intentional. controller: installPlugins: - kubernetes:latest - configuration-as-code:latest - workflow-aggregator:latest - git:latest JCasC: defaultConfig: true configScripts: clouds: | jenkins: clouds: - kubernetes: name: "k8s" namespace: "jenkins" jenkinsUrl: "http://jenkins.jenkins.svc:8080" containerCapStr: "50" templates: - name: "build-go" label: "go" containers: - name: "go" image: "golang:1.23" command: "sleep" args: "infinity" resourceRequestCpu: "1" resourceRequestMemory: "2Gi" resourceLimitMemory: "4Gi" security: | jenkins: authorizationStrategy: roleBased: roles: global: - name: "admin" permissions: ["Overall/Administer"] assignments: ["oidc-group-platform"] resources: requests: { cpu: "1", memory: "2Gi" } limits: { memory: "4Gi" } persistence: enabled: true storageClass: longhorn size: 50Gi agent: enabled: false # agents are defined in JCasC clouds above, not here ``` ```yaml # clusters/prod/apps/jenkins.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: jenkins-prod namespace: argocd spec: project: platform source: repoURL: https://git.internal/ops/gitops.git path: apps/overlays/prod/jenkins targetRevision: main destination: server: https://prod-api.internal:6443 namespace: jenkins syncPolicy: automated: { prune: true, selfHeal: true } syncOptions: ["CreateNamespace=true"] ``` ### CI/CD flow ที่ AI ไม่อยู่ใน path ```mermaid sequenceDiagram autonumber participant Dev as นักพัฒนา participant SCM as Git (app repo) participant J as Jenkins Controller (Pod) participant Ag as Jenkins Agent (ephemeral Pod) participant H as Harbor Registry participant G as Git (gitops repo) participant A as Argo CD participant C as Cluster Dev->>SCM: git push SCM->>J: webhook J->>Ag: สร้าง agent pod จาก podTemplate Ag->>Ag: build + unit test Ag->>Ag: trivy image scan (fail ถ้าเจอ CRITICAL) Ag->>H: push image:sha-abc123 Ag->>G: kustomize edit set image + push Ag-->>J: สำเร็จ แล้ว pod ถูกทำลาย G->>A: webhook A->>C: sync manifest C-->>A: Healthy / Degraded Note over A,C: เส้นทางนี้เป็นระบบอัตโนมัติล้วน
AI ไม่แตะเลยตอนทุกอย่างปกติ A-->>Dev: แจ้งผลผ่าน Slack/LINE ``` **ประเด็นสำคัญ:** AI ไม่ได้อยู่ในเส้นทาง deploy ปกติ หน้าที่ของ AI คือ **ดูแลเส้นทางนี้และซ่อมเมื่อมันพัง** ไม่ใช่มาแทนที่มัน ถ้าออกแบบให้ AI เป็นคนกด deploy ทุกครั้ง คุณจะได้ระบบที่ช้าลงและเปราะกว่าเดิม ### ซอฟต์แวร์อื่น ๆ เข้ามาด้วย pattern เดียวกัน | ประเภท | ตัวอย่าง | ข้อควรระวังที่ AI ต้องรู้ | |---|---|---| | CI/CD | Jenkins, Argo Workflows, Tekton | ต้องมี PVC + config-as-code | | Registry | Harbor, Zot | ต้องการ object storage + cert | | Database | CloudNativePG, Percona MySQL Operator | ใช้ Operator เท่านั้น ห้ามยัด StatefulSet ดิบ | | Message | Strimzi Kafka, RabbitMQ Operator | PDB + anti-affinity บังคับ | | Cache | Redis Operator | maxmemory-policy ต้องตั้ง | | Secret | OpenBao / Vault | unseal key ห้ามอยู่ใน cluster เดียวกัน | | Internal tool | Grafana, n8n, Gitea | ผ่าน SSO เท่านั้น | --- ## 10. Day-2 Operations — ตัวอย่างการทำงานจริง ### 10.1 วิเคราะห์ปัญหา ```mermaid sequenceDiagram autonumber actor U as คุณ participant AI as ai-ops-00 participant K as kube-apiserver (read-only) participant P as Prometheus participant L as Loki participant G as Git participant A as Argo CD U->>AI: "pod payment-api restart บ่อยมาก ช่วยดูให้ที" AI->>AI: อ่าน ops/runbooks/pod-crashloop.md AI->>K: get pod -n payment -l app=payment-api K-->>AI: restartCount=17, reason=OOMKilled AI->>L: query log 10 นาทีก่อน terminate L-->>AI: log แสดง batch job โหลด 200k row เข้า memory AI->>P: max_over_time(container_memory_working_set_bytes[7d]) P-->>AI: peak 980Mi / limit 512Mi และโตเป็นขั้นบันไดทุกวันจันทร์ Note over AI: สาเหตุยืนยัน = limit ต่ำเกินสำหรับ batch วันจันทร์
ไม่ใช่ memory leak เพราะกราฟลงกลับทุกวัน AI-->>U: รายงาน + เสนอ 2 ทาง
(1) ขึ้น limit 1.5Gi (2) แยก batch เป็น CronJob U->>AI: "เอาทาง 1 ไปก่อน แล้วเปิด issue ทาง 2 ไว้" AI->>G: แก้ apps/overlays/prod/payment-api + เปิด PR G-->>U: PR #482 พร้อม diff + วิธี rollback U->>G: approve + merge G->>A: webhook A->>K: sync (Argo เป็นคน apply ไม่ใช่ AI) AI->>P: เฝ้าดู 30 นาที AI-->>U: restart=0, peak 780Mi/1.5Gi ปกติแล้ว ``` ### 10.2 คำสั่งที่ใช้จริงในชีวิตประจำวัน ```bash cd /opt/ops/gitops && claude # ตรวจสุขภาพประจำวัน > ทำ health check ทุก cluster สรุปเป็นตาราง เอา node ที่ไม่ Ready, pod ที่ restart > 5 ครั้งใน 24 ชม., PVC ที่ใช้เกิน 80%, cert ที่หมดอายุใน 30 วัน, และ Argo app ที่ OutOfSync # เพิ่ม node > เพิ่ม worker node 3 เครื่องใน pool general สเปก 8c/32g ทำ tofu plan ให้ดูก่อน แล้วค่อยเปิด PR # ลงซอฟต์แวร์ใหม่ > ลง Harbor บน staging ใช้ Longhorn เป็น storage 200Gi ต่อ cert-manager ด้วย ClusterIssuer letsencrypt-prod ทำเป็น Argo Application แล้วเปิด PR # จูน > Prometheus กิน memory 12Gi เยอะไป ช่วยวิเคราะห์ว่า metric ตัวไหน cardinality สูงสุด 10 อันดับ แล้วเสนอ relabel drop # ตรวจก่อนขึ้นงาน > เช็ค prod ว่ามี workload ไหนไม่มี resource limits, ไม่มี PDB, หรือ replica=1 บ้าง ทำรายงานความเสี่ยง # หลังเกิดเหตุ > เขียน postmortem จาก incident เมื่อคืน ดึงข้อมูลจาก alertmanager + argo history + git log แล้วสร้าง runbook ใหม่ถ้ายังไม่มี ``` --- ## 11. การสเกล ```mermaid flowchart LR subgraph P1["Phase 1 — เริ่มต้น (1-2 สัปดาห์)"] A1[/"ai-ops-00"/] C1["cluster เดียว
3 control plane + 3 worker"] A1 --> C1 end subgraph P2["Phase 2 — แยก environment (1-2 เดือน)"] A2[/"ai-ops-00"/] M2["Management Cluster
Argo CD + Observability"] D2["Dev"] S2["Staging"] R2["Prod"] A2 --> M2 M2 ==> D2 M2 ==> S2 M2 ==> R2 end subgraph P3["Phase 3 — Fleet (6 เดือน+)"] A3[/"ai-ops-00 + ai-ops-01 แบบ HA"/] M3["Management Cluster
+ Cluster API + ApplicationSet"] F3[("Cluster Fleet
N clusters หลาย DC / หลาย region")] A3 --> M3 M3 ==> F3 M3 -.-> F3 end P1 --> P2 P2 --> P3 NT>"สิ่งที่ไม่เปลี่ยนทุก phase:
คนสั่งงานยังเป็นเครื่องเดียว และ Git ยังเป็นความจริงเดียว"] P3 -.- NT ``` ### สิ่งที่ต้องเปลี่ยนเมื่อโต | ตัวชี้วัด | เกณฑ์ | สิ่งที่ต้องทำ | |---|---|---| | จำนวน node | > 20 | ย้าย Longhorn → Rook-Ceph, แยก etcd ออกเป็น dedicated node | | จำนวน pod | > 3,000 | ปรับ `--max-requests-inflight`, แยก Prometheus เป็น shard + Thanos | | จำนวน cluster | > 3 | ใช้ ApplicationSet + Cluster API แทนการเขียน Application ทีละตัว | | จำนวนทีมใช้งาน | > 5 | vCluster หรือ namespace-as-a-service + ResourceQuota + hierarchical namespace | | metric cardinality | > 2M series | relabel drop + recording rule + ลด scrape interval | | ปริมาณ log | > 500 GB/วัน | Loki เป็น microservice mode + S3 backend + retention policy | Cluster API คือจุดที่ทำให้ AI สร้าง cluster ใหม่ได้เองด้วยการเขียน YAML: ```yaml # infrastructure/capi/cluster-prod-dc2.yaml # Declaring a whole new cluster is now just another manifest in Git. apiVersion: cluster.x-k8s.io/v1beta1 kind: Cluster metadata: name: prod-dc2 namespace: capi-clusters spec: clusterNetwork: pods: { cidrBlocks: ["10.244.0.0/16"] } services: { cidrBlocks: ["10.96.0.0/12"] } controlPlaneRef: apiVersion: controlplane.cluster.x-k8s.io/v1beta1 kind: TalosControlPlane name: prod-dc2-cp infrastructureRef: apiVersion: infrastructure.cluster.x-k8s.io/v1beta1 kind: ProxmoxCluster name: prod-dc2-infra ``` --- ## 12. Backup, DR และการกัน AI VM พัง `ai-ops-00` เป็น single point of failure แต่แก้ได้ง่ายมาก **ถ้ามันเป็น stateless จริง ๆ** | ของที่ต้องสำรอง | เก็บที่ไหน | ความถี่ | ทดสอบกู้คืน | |---|---|---|---| | Git repo | Gitea/GitLab + mirror ไป S3 อีกที่ | ทุก push | รายเดือน | | etcd snapshot | S3 (คนละ region) | ทุก 6 ชม. | รายไตรมาส | | PV data | Velero + Longhorn backup → S3 | รายวัน | รายไตรมาส | | age private key | HSM หรือ paper backup ในตู้เซฟ | ครั้งเดียว | รายปี | | Vault unseal key | Shamir split 3-of-5 คนละที่ | ครั้งเดียว | รายปี | | Container image | Harbor replication ไป registry สำรอง | ต่อเนื่อง | รายไตรมาส | **การกู้ `ai-ops-00`:** ```bash # Rebuild the control node from nothing in ~15 minutes curl -fsSL https://git.internal/ops/gitops/raw/main/ops/scripts/bootstrap-ai-ops.sh | bash git clone https://git.internal/ops/gitops.git /opt/ops/gitops # Restore the age key from the safe, then everything else follows from Git sops -d /opt/ops/gitops/ops/kubeconfig/ai-readonly.yaml.enc > /opt/ops/kubeconfig/ai-readonly.yaml ``` ถ้าขั้นตอนนี้เกิน 30 นาที แปลว่ามี state ตกค้างอยู่ในเครื่องที่ไม่ได้อยู่ใน Git — ต้องไปตามหาแล้วย้ายเข้า Git --- ## 13. แผนติดตั้งเป็น Phase | Phase | ระยะเวลา | สิ่งที่ทำ | เกณฑ์ว่าผ่าน | |---|---|---|---| | **0** | 2 วัน | สร้าง `ai-ops-00`, ลง tool ทั้งหมด, สร้าง Git repo, เขียน `CLAUDE.md` ฉบับแรก | AI ตอบ `kubectl version` ได้และรู้ว่าตัวเองมีข้อจำกัดอะไร | | **1** | 3 วัน | OpenTofu สร้าง VM, Talos/RKE2 bootstrap cluster แรก, Cilium + CoreDNS | `kubectl get nodes` เขียว 6 เครื่อง | | **2** | 3 วัน | Argo CD self-managed, ย้าย Cilium มาอยู่ใต้ Argo, MetalLB, Longhorn | ลบ Argo แล้วสร้างใหม่จาก Git ได้ | | **3** | 1 สัปดาห์ | cert-manager, Ingress/Gateway, kube-prometheus-stack, Loki, Alertmanager | AI ตอบ "cluster สุขภาพเป็นยังไง" ได้จากข้อมูลจริง | | **4** | 1 สัปดาห์ | Kyverno policy, RBAC read-only, break-glass, CI gate, audit log | AI พยายาม `kubectl delete ns` แล้วถูกบล็อกจริง | | **5** | 1 สัปดาห์ | Harbor, Jenkins + JCasC, Velero, External Secrets | deploy แอปตัวอย่างจบ loop ได้โดยไม่ต้องแตะ cluster | | **6** | ต่อเนื่อง | เขียน runbook ทีละใบจากปัญหาจริงที่เจอ | ทุก incident จบด้วย runbook ใหม่หรือ runbook ที่ปรับปรุงแล้ว | Phase 6 คือ phase ที่ไม่มีวันจบ และเป็น phase ที่ทำให้ระบบนี้มีค่าจริง — **คลัง runbook คือทรัพย์สินที่แท้จริง ไม่ใช่ตัว AI** --- ## 14. ข้อผิดพลาดที่ต้องหลีกเลี่ยง 1. **ให้ AI ถือ cluster-admin ตั้งแต่วันแรก** — จะเร็วมากในสัปดาห์แรก และเจ็บมากในเดือนที่สาม เริ่มจาก read-only เสมอแล้วค่อยเปิดทีละอย่างเมื่อมั่นใจ 2. **ไม่เขียน runbook เพราะ "AI จำได้"** — AI ไม่จำ context ข้ามเซสชัน และวันที่คุณเปลี่ยนโมเดล ความรู้ทั้งหมดหายไปพร้อมกัน 3. **ปล่อยให้ AI `ssh` เข้า node** — นี่คือประตูสู่ config drift ใช้ Talos ที่ไม่มี SSH เลยจะดีที่สุด ถ้าใช้ RHEL ก็ปิด SSH สำหรับ identity ของ AI 4. **เอา AI VM ไปรันบน cluster เดียวกัน** — cluster ล่มแล้วซ่อมไม่ได้ 5. **ไม่ทดสอบ restore** — backup ที่ไม่เคย restore ถือว่าไม่มี ตั้ง calendar ไว้เลย 6. **ให้ AI merge PR เอง** — human-in-the-loop ตรงนี้ราคาถูกมากเมื่อเทียบกับความเสียหายที่กันได้ 7. **เชื่อคำตอบ AI โดยไม่ดูหลักฐาน** — บังคับให้มันแสดง raw output ที่ใช้สรุปทุกครั้ง ระบุใน `CLAUDE.md` 8. **ลืมคุมค่า token** — health check ทุกชั่วโมงด้วยโมเดลใหญ่แพงกว่าจ้างคน; งาน routine ให้ใช้สคริปต์ธรรมดา เรียก AI เฉพาะตอนต้องคิด --- ## 15. สรุป สิ่งที่ออกแบบมานี้ไม่ใช่ "AI มาแทน DevOps" แต่คือ **การย้ายความรู้ของ DevOps ออกจากหัวคนไปอยู่ใน Git** แล้วให้ AI เป็นส่วนต่อประสานที่ทำให้ความรู้นั้นเรียกใช้ได้ด้วยภาษาไทยจาก CLI เครื่องเดียว - AI เก่งเรื่อง **อ่านสัญญาณเยอะ ๆ พร้อมกันแล้วสรุป** และ **เขียน YAML ตาม pattern** — จึงให้มันทำสองอย่างนี้ - AI ไม่เก่งเรื่อง **การตัดสินใจที่ย้อนกลับไม่ได้** — จึงกันไว้ด้วย GitOps + PR + policy - คุณค่าระยะยาวอยู่ที่ **runbook + policy + โครงสร้าง repo** ไม่ใช่ที่โมเดล เปลี่ยนโมเดลเมื่อไหร่ก็ได้โดยไม่เสียอะไร เริ่มจาก Phase 0 กับ cluster เดียว 6 เครื่อง แล้วเพิ่ม guardrail ก่อนเพิ่มสิทธิ์เสมอ --- ## ภาคผนวก: Checklist ก่อนขึ้น Production - [ ] etcd มี 3 หรือ 5 สมาชิก อยู่คนละ hypervisor host - [ ] snapshot etcd อัตโนมัติทุก 6 ชม. และ restore ทดสอบผ่านแล้ว - [ ] ทุก workload มี resource requests/limits (บังคับด้วย Kyverno) - [ ] ทุก workload ที่สำคัญมี PDB + anti-affinity + replica ≥ 2 - [ ] cert-manager ต่อ Alertmanager แจ้งเตือนก่อนหมดอายุ 30 วัน - [ ] AI ใช้ identity read-only และผ่านการทดสอบว่าลบอะไรไม่ได้จริง - [ ] break-glass ทดสอบแล้วและมี audit log ครบ - [ ] Velero backup ทุกวัน และ restore ทดสอบแล้วอย่างน้อย 1 ครั้ง - [ ] Argo CD `selfHeal: true` เปิดทุก app — ใครแก้มือบน cluster จะถูกย้อนกลับอัตโนมัติ - [ ] มี runbook อย่างน้อย 10 ใบครอบคลุมอาการที่พบบ่อย - [ ] ซ้อม DR เต็มรูปแบบ 1 ครั้ง โดยสมมติว่า `ai-ops-00` และ 1 control plane หายพร้อมกัน

SECURE_ACCESS

DOWNLOAD_LOCKED

สร้าง Kubernetes ไว้ใช้เอง

CONFIRM_DELETE