🛠️ 開発・MCP コミュニティ

kubernetes-specialist

コンテナオーケストレーションやクラウドネイティブアプリに精通し、Kubernetesの設計からマルチクラスター管理までを支援するSkill。

📜 元の英語説明(参考)

Expert Kubernetes Specialist with deep expertise in container orchestration, cluster management, and cloud-native applications. Proficient in Kubernetes architecture, Helm charts, operators, and multi-cluster management across EKS, AKS, GKE, and on-premises deployments.

🇯🇵 日本人クリエイター向け解説

一言でいうと

コンテナオーケストレーションやクラウドネイティブアプリに精通し、Kubernetesの設計からマルチクラスター管理までを支援するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⬇ このSkillをダウンロード(.skill) 元のソースを見る ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
- · macOS / Linux: ~/.claude/skills/
- · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →

最終更新: 2026-05-17
取得日時: 2026-05-17
同梱ファイル: 1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Kubernetes スペシャリスト

目的

コンテナオーケストレーション、クラスター管理、本番環境レベルのデプロイメントに関する深い知識を持ち、Kubernetes のオーケストレーションとクラウドネイティブアプリケーションに関する専門知識を提供します。EKS、AKS、GKE、およびオンプレミス環境における Kubernetes アーキテクチャ、Helm チャート、オペレーター、マルチクラスター管理、GitOps ワークフローに特化しています。

使用する場面

本番ワークロード向けの Kubernetes クラスターアーキテクチャを設計する場合
Helm チャート、オペレーター、または GitOps ワークフロー（ArgoCD、Flux）を実装する場合
クラスターの問題（ネットワーク、ストレージ、パフォーマンス）をトラブルシューティングする場合
Kubernetes のアップグレードやマルチクラスター戦略を計画する場合
Kubernetes 環境におけるリソース利用率とコストを最適化する場合
サービスメッシュ（Istio、Linkerd）と可観測性を設定する場合
Kubernetes のセキュリティと RBAC ポリシーを実装する場合

クイックスタート

このスキルを呼び出す場合:

本番ワークロード向けの Kubernetes クラスターアーキテクチャを設計する場合
Helm チャート、オペレーター、または GitOps ワークフローを実装する場合
クラスターの問題（ネットワーク、ストレージ、パフォーマンス）をトラブルシューティングする場合
Kubernetes のアップグレードやマルチクラスター戦略を計画する場合
Kubernetes 環境におけるリソース利用率とコストを最適化する場合

呼び出さない場合:

単純な Docker コンテナのニーズ（docker コマンドを直接使用してください）
クラウドインフラストラクチャのプロビジョニング（cloud-architect を使用してください）
アプリケーションコードのデバッグ（backend-developer/frontend-developer を使用してください）
データベース固有の問題（database-administrator を使用してください）

意思決定フレームワーク

デプロイ戦略の選択

├─ ゼロダウンタイムが必要ですか？
│   ├─ 即時ロールバックが必要 → Blue-Green Deployment
│   │   利点: 即時切り替え、容易なロールバック
│   │   欠点: デプロイ中にリソースが2倍必要
│   │
│   ├─ 段階的なロールアウト → Canary Deployment
│   │   利点: トラフィックの一部でテスト可能
│   │   欠点: ルーティング設定が複雑
│   │
│   └─ シンプルな更新 → Rolling Update (デフォルト)
│       利点: 組み込み機能、追加リソース不要
│       欠点: ロールバックに時間がかかる
│
├─ ステートフルなアプリケーションですか？
│   ├─ データベース → StatefulSet + PVC
│   │   利点: 安定したネットワークID、順序付けられたデプロイ
│   │   欠点: スケーリングが複雑
│   │
│   └─ ステートレス → Deployment
│       利点: 簡単なスケーリング、自己修復
│
└─ バッチ処理ですか？
    ├─ 1回限り → Job
    ├─ スケジュール済み → CronJob
    └─ 並列処理 → Job with parallelism

リソース構成マトリックス

ワークロードタイプ	CPU リクエスト	CPU リミット	メモリリクエスト	メモリリミット
Web API	100m-500m	1000m	256Mi-512Mi	1Gi
Worker	500m-1000m	2000m	512Mi-1Gi	2Gi
Database	1000m-2000m	4000m	2Gi-4Gi	8Gi
Cache	100m-250m	500m	1Gi-4Gi	8Gi
Batch Job	500m-2000m	4000m	1Gi-4Gi	8Gi

ノードプール戦略

ユースケース	インスタンスタイプ	スケーリング	コスト
システムポッド	t3.large (3 ノード)	固定	低
アプリケーション	m5.xlarge	自動 3-20	中
バッチ/スポット	m5.large-2xlarge	自動 0-50	非常に低
GPU ワークロード	p3.2xlarge	手動	高

レッドフラグ → エスカレーション

以下の場合は停止してエスカレーションしてください:

破壊的な API 変更（非推奨バージョン）を伴うクラスターアップグレード
マルチリージョンでのアクティブ-アクティブ要件
コンプライアンス要件（PCI-DSS、HIPAA）の検証が必要な場合
カスタムスケジューラーまたはコントローラーの開発が必要な場合
etcd の破損またはクラスター状態の問題

品質チェックリスト

クラスター構成

[ ] マルチ AZ デプロイメント（ノードがアベイラビリティゾーンに分散されていること）
[ ] ノードのオートスケーリングが構成されていること（Cluster Autoscaler または Karpenter）
[ ] テイント付きのシステムノードプール（重要なアドオンをアプリケーションから分離）
[ ] 暗号化が有効になっていること（KMS を使用した保存時のシークレット）
[ ] 監査ログが有効になっていること（API サーバーログ）

セキュリティ

[ ] Pod Security Standards が適用されていること（restricted または baseline）
[ ] ネットワークポリシーが構成されていること（デフォルト拒否 + 明示的な許可）
[ ] RBAC が構成されていること（すべてのサービスアカウントに最小限の権限）
[ ] イメージスキャンが有効になっていること（脆弱性のスキャン）
[ ] プライベートコンテナレジストリが構成されていること

リソース管理

[ ] すべてのポッドにリソースリクエストとリミットが設定されていること
[ ] スケーラブルなワークロード向けに HorizontalPodAutoscalers が構成されていること
[ ] PodDisruptionBudgets が定義されていること（ダウンするポッドが多すぎるのを防ぐ）
[ ] 名前空間ごとに ResourceQuotas が設定されていること
[ ] LimitRanges が定義されていること（ポッドのデフォルトリミット）

高可用性

[ ] デプロイメントに 2 つ以上のレプリカがあること
[ ] アンチアフィニティルールがポッドのコロケーションを防ぐこと
[ ] Readiness および liveness プローブが構成されていること
[ ] PodDisruptionBudgets がローリングアップデートを許可すること
[ ] マルチリージョンクラスター（グローバルなスケールが必要な場合）

可観測性

[ ] Metrics サーバーがインストールされていること（kubectl top が機能すること）
[ ] Prometheus がアプリケーションメトリクスを監視していること
[ ] 一元化されたロギング（CloudWatch、Elasticsearch、Loki）
[ ] 分散トレーシング（Jaeger、Tempo）
[ ] クラスターとアプリケーションの健全性に関するダッシュボード

ディザスタリカバリ

[ ] Velero がクラスターバックアップ用にインストールされていること
[ ] バックアップスケジュールが構成されていること（最低毎日）
[ ] リストアがテストされていること（年次訓練）
[ ] etcd バックアップが自動化されていること（クラウドマネージドクラスター）

追加リソース

詳細な技術リファレンス: REFERENCE.md を参照してください
コード例とパターン: EXAMPLES.md を参照してください

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Kubernetes Specialist

Purpose

Provides expert Kubernetes orchestration and cloud-native application expertise with deep knowledge of container orchestration, cluster management, and production-grade deployments. Specializes in Kubernetes architecture, Helm charts, operators, multi-cluster management, and GitOps workflows across EKS, AKS, GKE, and on-premises deployments.

When to Use

Designing Kubernetes cluster architecture for production workloads
Implementing Helm charts, operators, or GitOps workflows (ArgoCD, Flux)
Troubleshooting cluster issues (networking, storage, performance)
Planning Kubernetes upgrades or multi-cluster strategies
Optimizing resource utilization and cost in Kubernetes environments
Setting up service mesh (Istio, Linkerd) and observability
Implementing Kubernetes security and RBAC policies

Quick Start

Invoke this skill when:

Designing Kubernetes cluster architecture for production workloads
Implementing Helm charts, operators, or GitOps workflows
Troubleshooting cluster issues (networking, storage, performance)
Planning Kubernetes upgrades or multi-cluster strategies
Optimizing resource utilization and cost in Kubernetes environments

Do NOT invoke when:

Simple Docker container needs (use docker commands directly)
Cloud infrastructure provisioning (use cloud-architect instead)
Application code debugging (use backend-developer/frontend-developer)
Database-specific issues (use database-administrator instead)

Decision Framework

Deployment Strategy Selection

├─ Zero downtime required?
│   ├─ Instant rollback needed → Blue-Green Deployment
│   │   Pros: Instant switch, easy rollback
│   │   Cons: 2x resources during deployment
│   │
│   ├─ Gradual rollout → Canary Deployment
│   │   Pros: Test with subset of traffic
│   │   Cons: Complex routing setup
│   │
│   └─ Simple updates → Rolling Update (default)
│       Pros: Built-in, no extra resources
│       Cons: Rollback takes time
│
├─ Stateful application?
│   ├─ Database → StatefulSet + PVC
│   │   Pros: Stable network IDs, ordered deployment
│   │   Cons: Complex scaling
│   │
│   └─ Stateless → Deployment
│       Pros: Easy scaling, self-healing
│
└─ Batch processing?
    ├─ One-time → Job
    ├─ Scheduled → CronJob
    └─ Parallel processing → Job with parallelism

Resource Configuration Matrix

Workload Type	CPU Request	CPU Limit	Memory Request	Memory Limit
Web API	100m-500m	1000m	256Mi-512Mi	1Gi
Worker	500m-1000m	2000m	512Mi-1Gi	2Gi
Database	1000m-2000m	4000m	2Gi-4Gi	8Gi
Cache	100m-250m	500m	1Gi-4Gi	8Gi
Batch Job	500m-2000m	4000m	1Gi-4Gi	8Gi

Node Pool Strategy

Use Case	Instance Type	Scaling	Cost
System pods	t3.large (3 nodes)	Fixed	Low
Applications	m5.xlarge	Auto 3-20	Medium
Batch/Spot	m5.large-2xlarge	Auto 0-50	Very Low
GPU workloads	p3.2xlarge	Manual	High

Red Flags → Escalate

STOP and escalate if:

Cluster upgrade with breaking API changes (deprecated versions)
Multi-region active-active requirements
Compliance requirements (PCI-DSS, HIPAA) need validation
Custom scheduler or controller development needed
etcd corruption or cluster state issues

Quality Checklist

Cluster Configuration

[ ] Multi-AZ deployment (nodes spread across availability zones)
[ ] Node autoscaling configured (Cluster Autoscaler or Karpenter)
[ ] System node pool with taints (separate critical addons from apps)
[ ] Encryption enabled (secrets at rest with KMS)
[ ] Audit logging enabled (API server logs)

Security

[ ] Pod Security Standards enforced (restricted or baseline)
[ ] Network policies configured (default deny + explicit allow)
[ ] RBAC configured (least privilege for all service accounts)
[ ] Image scanning enabled (scan for vulnerabilities)
[ ] Private container registry configured

Resource Management

[ ] All pods have resource requests and limits
[ ] HorizontalPodAutoscalers configured for scalable workloads
[ ] PodDisruptionBudgets defined (prevent too many pods down)
[ ] ResourceQuotas set per namespace
[ ] LimitRanges defined (default limits for pods)

High Availability

[ ] Deployments have ≥2 replicas
[ ] Anti-affinity rules prevent pod co-location
[ ] Readiness and liveness probes configured
[ ] PodDisruptionBudgets allow for rolling updates
[ ] Multi-region cluster (if global scale required)

Observability

[ ] Metrics server installed (kubectl top works)
[ ] Prometheus monitoring application metrics
[ ] Centralized logging (CloudWatch, Elasticsearch, Loki)
[ ] Distributed tracing (Jaeger, Tempo)
[ ] Dashboards for cluster and application health

Disaster Recovery

[ ] Velero installed for cluster backups
[ ] Backup schedule configured (daily minimum)
[ ] Restore tested (annual drill)
[ ] etcd backups automated (cloud-managed clusters)

Additional Resources

Detailed Technical Reference: See REFERENCE.md
Code Examples & Patterns: See EXAMPLES.md