#Kubernetes
136 件の記事
Certified Kubernetes Administrator (CKA) #2 クラスターアーキテクチャ 1: Control plane (apiserver/etcd/scheduler/controller-manager)
Certified Kubernetes Administrator (CKA) シリーズの 2 番目の記事です。クラスターがどう動くのかを control plane から覗いていきます。kube-apiserver (すべての通信の関所)、etcd (クラスター状態の保存先)、kube-scheduler (Pod 配置の決定)、kube-controller-manager (reconciliation loop) がそれぞれ何をするのか、control plane がどのように static Pod として起動しているのか、そしてコンポーネントが死ぬとクラスターに何が起きるのかを運用者の視点で整理します。
Certified Kubernetes Administrator (CKA) #1: 試験環境: alias と dry-run、vim/yq セットアップ、時間管理
Certified Kubernetes Administrator (CKA) シリーズの最初の記事です。2 時間の実技試験の構造と 5 つのドメインの比重 (Troubleshooting 30% が核心)、合格ラインと受験環境を整理し、試験時間を左右するセットアップ (alias、dry-run、vim/yq、etcdctl、systemctl) を手に覚えさせます。本シリーズは CKA 合格を目標にする 27 編で、最後の #27 で実技模擬試験を解きます。
K8s 実戦 #6 運用チェックリスト — アップグレード / バックアップ・リカバリ / コスト / セキュリティ
K8s 実戦シリーズの最後の記事です。クラスタを安定的に立てることと 1 年間安全に運用することは異なる性質の作業です。EKS クラスタアップグレードサイクル、ノードグループ交換パターン、RDS 自動バックアップと PITR、Karpenter と Spot でコストを押さえる道、kube-bench と Trivy でセキュリティ点検を定期化する流れまでまとめます。最後の記事なので K8s 実戦 6 編の振り返りと 26 編の K8s トラック全体の振り返りも一緒に入れます。
K8s 実戦 #5 モニタリング・アラーム — Prometheus / CloudWatch / Alertmanager
[#4](/ja/posts/k8s-practice-4) まで作った myshop-api はコードからデプロイまで自動化されましたが、その動作を見ないと運用が回りません。この記事では EKS クラスタのオブザーバビリティスタックを整理します。kube-prometheus-stack で Prometheus + Grafana + Alertmanager を一度にインストールし、Container Insights と Fluent Bit で CloudWatch にメトリクス・ログを送る 2 軸を結合し、ServiceMonitor / PrometheusRule で myshop-api メトリクスとアラームを標準化し、4 golden signals のルールセットと Slack / PagerDuty ルーティングで on-call 流れまでまとめます。
K8s 実戦 #4 CI/CD パイプライン — GitHub Actions / ECR / ArgoCD
[#3](/ja/posts/k8s-practice-3) まで作った myshop-api は新しいバージョンが入ってくる過程が人の手に縛られています。この記事ではその過程を自動化します。GitHub Actions で OIDC を使って静的キーなしに AWS ECR にコンテナイメージを push し、マニフェスト repo の Helm values を自動 commit して [上級 #6](/ja/posts/k8s-advanced-6) で扱った ArgoCD がその変更を検知してクラスタに同期する流れをまとめます。PR 承認ゲート、dev/prod 分岐、カナリーデプロイまで一緒に押さえます。
K8s 実戦 #3 DB 連動 — RDS / Secrets Manager / External Secrets / コネクションプール
[#2](/ja/posts/k8s-practice-2) で外部公開まで作った myshop-api はデータストアが空の殻です。この記事では RDS PostgreSQL を Terraform で立てて、AWS Secrets Manager にマスター秘密を置き、External Secrets Operator でその秘密を K8s Secret に自動同期し、IRSA で静的資格情報なしにアクセスし、PgBouncer でコネクションプールまで載せる運用流れをまとめます。スキーマ移行を Job で自動化するパターンも一緒に押さえます。
K8s 実戦 #2 アプリデプロイ骨格 — Deployment / Service / Ingress / Helm
[#1](/ja/posts/k8s-practice-1) で立てた空の EKS クラスタに myshop-api を載せる段階です。Deployment / Service / Ingress / ConfigMap / Secret / ServiceAccount / HPA を 1 セットで整理し、AWS Load Balancer Controller で ALB を自動プロビジョニングし、その束を Helm chart で抽象化して dev / prod に同じ chart が異なる values でデプロイされる流れまで 1 サイクルでまとめます。
K8s 実戦 #1 EKS クラスタセットアップ — Terraform / eksctl / IRSA / アドオン
K8s 実戦シリーズの最初の記事です。抽象ではなく実際の運用クラスタを構成する流れを追います。Terraform で VPC と EKS クラスタを定義し、ノードグループと IRSA をセットアップし、必須アドオン(VPC CNI、CoreDNS、kube-proxy、EBS CSI)まで載せる流れです。早いセットアップが必要なときの eksctl オプションも一緒に比較します。6 編全体で使う仮想サービス myshop-api のためのクラスタの出発点を作る最初の記事です。
K8s 高級 #6 GitOps — ArgoCD / Flux
K8s 高級シリーズの最後の記事です。マニフェストの source of truth を git に置き、クラスタ内のコントローラが git を watch して同期する運用モデル — GitOps をまとめます。push モデルと pull モデルの違い、ArgoCD の Application CRD と sync wave、Flux の Source / Kustomization / HelmRelease、ディレクトリ構造パターン、Sealed Secrets / External Secrets で秘密を git に安全に置く道までがこの記事の範囲です。シリーズ最後の記事なので K8s 高級 6 編の振り返りと次のトラック K8s 実戦の予告も一緒に入れます。
K8s 高級 #5 オブザーバビリティ — Prometheus / Grafana / Loki / OpenTelemetry
運用クラスタのオブザーバビリティはメトリクス、ログ、トレースの 3 軸で構成されます。各軸の K8s 標準スタックはほぼ固まっています。メトリクスは Prometheus + kube-state-metrics + node-exporter、ログは Loki(または EFK)、トレースは OpenTelemetry、可視化は Grafana、アラームは Alertmanager。この記事では 3 軸のモデルと各軸の標準コンポーネント、そしてカーディナリティ・保存期間・アラーム設計のような運用原則を 1 サイクルでまとめます。
K8s 高級 #4 CRD と Operator パターン — controller-runtime
K8s が強力な理由の 1 つは自分の API 自体を拡張できる点です。CustomResourceDefinition で新しいオブジェクト種を定義し、controller-runtime でそのオブジェクトに対する reconcile ループを書けば K8s の上に私たちのドメインのオブジェクトが標準リソースのように住むことになります。PostgresCluster、RedisFailover、KafkaBroker のような名前のオブジェクトがその結果物です。この記事では CRD のモデル、controller-runtime ベースの Operator 骨格、ownerReference / finalizer / status subresource まで 1 サイクルでまとめます。
K8s 高級 #3 Admission Controller — OPA Gatekeeper / Kyverno
K8s API サーバはマニフェストを etcd に保存する直前に検査して変形できる段階を持っています。Admission Controller というこの段階が運用クラスタのポリシーエンジンが入る道です。「limits なしのコンテナを拒否」「特定ラベルを強制」「イメージの出所を制限」のようなポリシーをコード 1 行も変えずにマニフェスト次元で防ぎます。この記事では admission 段階の位置、ビルトインコントローラ、ValidatingWebhook と MutatingWebhook、そして 2 つのポリシーエンジン OPA Gatekeeper と Kyverno のモデルを 1 サイクルでまとめます。