jpskill.com
🛠️ 開発・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本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux 
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o kubernetes-specialist.zip https://jpskill.com/download/6683.zip && unzip -o kubernetes-specialist.zip && rm kubernetes-specialist.zip
🪟 Windows (PowerShell) 
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/6683.zip -OutFile "$d\kubernetes-specialist.zip"; Expand-Archive "$d\kubernetes-specialist.zip" -DestinationPath $d -Force; ri "$d\kubernetes-specialist.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して kubernetes-specialist.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → kubernetes-specialist フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動
⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

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

🎯 このSkillでできること

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

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

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 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