Kubernetes FAQ

Does Pulumi create and manage Kubernetes clusters, or deploy workloads to running clusters?

Pulumi handles both cases, and we highly encourage you to try them together! Pulumi’s SDKs handle the various layers of infrastucture needed to define, provision, and operate Kubernetes clusters (managed or self-managed), their underlying dependencies, and the app workloads intended to run in-cluster.

Is the Pulumi Kubernetes API compatible with Kubernetes resource API?

The SDK API is 100% compatible with Kubernetes resource API, and is schematically identical to what Kubernetes users expect.

In fact, Pulumi’s Kubernetes SDK are manufactured by automatically wrapping our library functionality around the Kubernetes resource OpenAPI spec as soon as a new version is released! Ultimately, this means that Pulumi users do not have to learn a new Kubernetes API model, nor wait long to work with the latest versions available. See the Kubernetes and Pulumi API documentation for more details.

Notably, Pulumi also supports alpha and beta APIs.

Does Pulumi work with my kubeconfig file?

Yes! Pulumi uses the official Kubernetes client-go library to interact with the Kubernetes cluster. It will work pretty much anywhere kubectl works.

How does Pulumi compare to kubectl?

Pulumi is intended to be a drop-in replacement for kubectl. Though kubectl and Pulumi differ, functionally speaking, Pulumi works with the Kubernetes API Server to accomplish the same deployment goals as kubectl. Pulumi, like kubectl, can be used with any cluster as long as you have a kubeconfig file.

Most users use Pulumi to manage Kubernetes resources, but still use kubectl’s rich commands for examining cluster state (e.g., describe, explain, get, and so on).

The differences between the two are:

How does Pulumi compare to Helm?

Helm v2 allows users to easily install pre-packaged application charts into a Kubernetes cluster. Charts are parameterized by some number of values, which users can fill in to customize their application.

Can I use my existing YAML manifests and Helm Charts?

Pulumi has integration support for Kubernetes YAML manifests and Helm Charts. This support allows users to jumpstart their Pulumi experience by easily integrating existing Kubernetes workloads with new Pulumi code.


YAML Manifest:

import * as k8s as "@pulumi/kubernetes";

const myapp = new k8s.yaml.ConfigFile("app", {file: "app.yaml"});

Helm Chart:

import * as k8s as "@pulumi/kubernetes";

// Deploy a version of the stable/wordpress chart.
const wordpress = new k8s.helm.v3.Chart("wpdev", {
    repo: "stable",
    version: "2.1.3",
    chart: "wordpress"

See the pulumi/examples repo for more details.

Does the Pulumi Service see my credentials in the kubeconfig file?

No. Only the pulumi CLI tool running locally in the user’s client can read the kubeconfig file or execute resource operations on the cluster.

The service is used to coordinate multiple user updates, so they don’t update the same resources concurrently, and stores the state history of your deployments.

If you ask Pulumi to boot up a cluster (e.g., as our EKS example shows), then it is possible to retrieve a kubeconfig file for that cluster only. In this case, the kubeconfig file is stored as part of the state history of rollouts – but they are considered opaque state by the Pulumi service. The service never uses these values for any reason whatsoever.

Additionally, the contents of the kubeconfig files are not sensitive for managed clusters on the major cloud providers, as they defer authentication to their local CLIs.

Does the Pulumi Service see my cloud provider credentials?

No. The pulumi CLI tool runs locally in the user’s client. This allows Pulumi to transparently rely on the underlying cloud provider’s CLI and authentication mechanisms. The service does not read, use, depend on, or store any credentials.

Can I use Pulumi without the pulumi.com service?

Yes. The service performs several functions that are useful, such as coordinating so that multiple users don’t simultaneously update the same resources, state checkpointing & management, webhooks, secrets management, and team auth, RBAC, and policies.

If you do not need these features, then you can have Pulumi store the state file somewhere else (e.g., in a local file, or in object storage). See documentation for pulumi login and pulumi #2455.

Learn more

Discover the getting started guides, and learn about Pulumi concepts.

Explore Docs

Contact us

Have questions about Pulumi? We're happy to help.

Contact Us