菜单
Native Kubernetes components (experimental): render/plan/diff/apply/deploy/delete/validate via Kubernetes Go SDK server-side apply, components.kubernetes, kubectl/kustomize providers, paths/manifests, provision targets (cluster vs. GitOps repo), and auth
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/cloudposse/atmos --skill atmos-kubernetes命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | atmos-kubernetes |
| description | Native Kubernetes components (experimental): render/plan/diff/apply/deploy/delete/validate via Kubernetes Go SDK server-side apply, components.kubernetes, kubectl/kustomize providers, paths/manifests, provision targets (cluster vs. GitOps repo), and auth |
| metadata | {"copyright":"Copyright Cloud Posse, LLC 2026","version":"1.0.0","category":"orchestrators"} |
Use this skill for the native Kubernetes component type (components.kubernetes). It manages
plain YAML/JSON manifests and Kustomize overlays through the Kubernetes Go SDK with server-side
apply. No kubectl or kustomize binary is required. This is distinct from Helm chart deployment —
see atmos-helm for charts, or atmos-helmfile
for Helmfile-based releases.
This feature is experimental (IsExperimental() == true in cmd/kubernetes/kubernetes.go).
kubectl/kustomize names describe manifest-processing behavior, not the CLI binaries.
| Need | Load |
|---|---|
| Helm charts (native, Helm Go SDK) | atmos-helm |
| Helmfile-based Kubernetes deployments |
| atmos-helmfile |
Component dependency ordering for --all/--affected | atmos-components |
GitOps delivery targets (provision.targets, kind: git) | atmos-git |
| EKS kubeconfig / cluster authentication | atmos-aws-eks, atmos-auth |
| Lifecycle hooks around component operations | atmos-hooks |
| Native CI job summaries | atmos-ci |
| Local Kubernetes emulator (k3s) | atmos-emulator |
Define Kubernetes objects under components.kubernetes in stack manifests:
components:
kubernetes:
argocd:
provider: kustomize
paths:
- overlays/{{ .vars.cluster }}
vars:
namespace: argocd
cluster: dev
env:
KUBECONFIG: /tmp/kubeconfig
manifests:
- apiVersion: v1
kind: Namespace
metadata:
name: "{{ .vars.namespace }}"
provision:
default: cluster
targets:
cluster:
kind: kubernetes
deployment-repo:
kind: git
repository: deployments
path: "clusters/{{ .vars.cluster }}/argocd"
Kubernetes components use the same stack sections as other component types — vars, env, auth,
metadata, settings, dependencies, hooks, generate, source/provision, inheritance, and
overrides. Kubernetes components do not support command — provider names describe manifest
behavior, and Atmos never shells out to kubectl/kustomize.
| Field | Purpose |
|---|---|
provider | kubectl (plain YAML/JSON) or kustomize (Kustomize overlays). Defaults to atmos.yaml components.kubernetes.provider (default kubectl). |
paths | Files or directories relative to the component directory. Directories are walked recursively for .yaml/.yml/.json. With provider: kustomize, a directory containing a Kustomize file is rendered as a Kustomize root. |
manifests | Inline Kubernetes objects (or YAML strings), merged with objects loaded from paths. |
render | Default output for atmos kubernetes render (output.path, output.split). |
provision | Delivery targets for apply/deploy — the cluster (default) or an external target such as a Git deployment repository. |
| Provider | Behavior |
|---|---|
kubectl | Loads plain YAML/JSON manifests from files, directories, and inline manifests. |
kustomize | Renders Kustomize directories via the Kustomize Go API, then passes objects to the same Kubernetes clients. |
Both providers are Go-SDK-based; neither requires the matching CLI binary installed.
| Command | Purpose |
|---|---|
atmos kubernetes render <component> -s <stack> | Resolve stack config, run generation, load manifests, render provider inputs, write final YAML. Does not contact the API server. |
atmos kubernetes validate <component> -s <stack> | Offline structural checks by default (apiVersion/kind present, metadata.name valid DNS-1123, resolvable GVK); --server adds a live server-side dry-run apply. Reports every invalid object, not just the first. |
atmos kubernetes diff <component> -s <stack> | Server-side dry-run apply against the live object, normalizes volatile metadata, reports created/changed/no-change per object with a unified diff. plan is an alias. |
atmos kubernetes apply <component> -s <stack> | Resolves each object GVK→GVR via discovery/RESTMapper, applies via the dynamic client with server-side apply, or delivers to a --target provision target. |
atmos kubernetes deploy <component> -s <stack> | Alias for apply; use when automation language should read as an application deployment rather than an API operation. |
atmos kubernetes delete <component> -s <stack> | Deletes the rendered objects from the cluster. |
All operation commands accept --all, --affected (with --base/--ref/--sha/--repo-path/
--clone-target-ref/--ssh-key/--ssh-key-password), and --include-dependents, matching
atmos describe affected semantics. --all/--affected are mutually exclusive with a positional
component argument. kubernetes aliases to k8s.
render writes multi-document YAML to stdout by default. --output <file> writes a single file;
--output-dir <dir> (with optional --split) writes one file per object (or manifest.yaml without
--split). These flags only work rendering a single component — set component-level render.output
for --all/--affected runs.
Runs the same offline structural checks automatically before apply/deploy, so malformed manifests
are rejected before anything reaches the cluster or a provision target. --server additionally
requires a reachable cluster/kubeconfig and surfaces schema errors and missing CRDs authoritatively.
atmos kubernetes diff does not shell out to kubectl diff. Secret objects are omitted from
diff output and CI summaries.
By default apply/deploy applies to the cluster (kind: kubernetes). A component can instead
publish rendered manifests to a Git deployment repository reconciled by Argo CD/Flux (kind: git):
git:
repositories:
deployments:
uri: https://github.com/acme/deployments.git
branch: main
components:
kubernetes:
argocd:
provision:
default: cluster # used when --target is omitted
targets:
cluster:
kind: kubernetes
deployment-repo:
kind: git
repository: deployments # references git.repositories.<name>
path: "clusters/{{ .vars.cluster }}/argocd"
auth:
identity: platform-admin # optional; else the repository default
commit:
message: "Render {{ .vars.app_name }} for {{ .vars.stage }}"
signing: auto # auto | always | never
atmos kubernetes deploy argocd -s plat-ue2-dev --target=deployment-repo
The git target clones (or fast-forwards), replaces the managed path with the rendered manifests,
commits with provenance trailers (Atmos-Stack, Atmos-Component), and pushes. Re-delivering
identical manifests is a clean no-op. Credentials come from Atmos Auth (GitHub STS) — never written
into the manifests. Pull-request publishing is not yet supported. See
atmos-git for the underlying mechanics.
Kubernetes operations use whatever kubeconfig/client configuration is visible to the Kubernetes Go client; Atmos Auth prepares that environment before the SDK client is created.
Local/ambient clusters:
auth:
identities:
local-k3s:
kind: ambient
components:
kubernetes:
app:
env:
KUBECONFIG: /path/to/kubeconfig
EKS clusters — chain an aws/eks integration off an AWS identity to resolve the cluster and write
kubeconfig before the Kubernetes command runs:
auth:
identities:
platform-admin:
kind: aws
integrations:
prod/eks:
kind: aws/eks
via:
identity: platform-admin
spec:
cluster:
name: acme-prod-eks
region: us-east-1
kubeconfig:
path: /tmp/acme-prod-kubeconfig
update: replace
See atmos-aws-eks for the full aws/eks integration contract.
components:
kubernetes:
base_path: components/kubernetes # default: components/kubernetes
provider: kubectl # default provider: kubectl | kustomize
auto_generate_files: false # render component `generate:` before operations
When ci.enabled: true and Atmos runs in a supported CI provider (e.g. GitHub Actions), Kubernetes
commands write a compact Markdown job summary ($GITHUB_STEP_SUMMARY) — summaries only (no
$GITHUB_OUTPUT, commit statuses, PR comments, or artifacts):
| Command | Summary content |
|---|---|
render | Rendered objects. |
plan/diff | Created/changed/no-change counts, plus a collapsible Kubernetes Diff block (per-object unified diff; Secret objects omitted). |
apply/deploy | Applied or delivered objects. |
delete | Deleted and not-found objects. |
validate | Valid and invalid objects. |
Dotted lifecycle events: before/after × kubernetes.{render,plan,diff,apply,deploy,delete,validate}.
plan normalizes to the diff lifecycle and deploy normalizes to the apply lifecycle for hook
matching, so hooks written for either spelling match the equivalent operation.
components:
kubernetes:
argocd:
hooks:
notify:
events:
- after.kubernetes.apply
command: echo "applied argocd"
validate (offline by default) before wiring --server dry-run checks that need a reachable
cluster — it catches structural errors (bad apiVersion/kind, invalid metadata.name) for free.dependencies.components so --all/--affected apply objects across components in the right
order.provision.targets with kind: git for GitOps delivery instead of ad hoc scripts that render
and commit manifests manually.kustomize provider when component paths are Kustomize roots; use kubectl provider for
plain manifest files/directories — both avoid needing the matching CLI binary installed.Secret objects never appear in diff output or CI summaries — don't rely on diff/CI logs
to review secret contents.