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:

• The Pulumi CLI presents information-rich status updates, clearly showing progress as resources come online or fail within the cluster. kubectl users must manually retreive these updates from the cluster with repeated calls.

• Pulumi allows you to preview the effects a change will have on your resource configuration.

• Pulumi provides full lifecycle management (creation, deletion, replacement) of resources. If we must change an immutable field in an API object, pulumi preview alerts the user the object must be replaced.

• The primary interface to kubectl is YAML. Pulumi exposes a rich, multi-language SDK to create API resources, and additionally supports execution of Kubernetes YAML manifests and Helm charts.

• kubectl has a set of commands specifically meant to make it easy to understand what’s happening in the cluster. Pulumi only does API resource management.

• Pulumi has a notion of resource initialization completion, allowing resources be configured using values from the live object. For example, a Deployment might boot a database, then parse the connection string, then put that in a secret, then reference that secret in a Pod. As of Kubernetes v1.12, kubectl can also wait for resource initialization, though it only supports applying all resource configuration at one time.

• Pulumi makes it easy to deploy the same app workload multiple times with default auto-naming.

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.

• By default, Helm 2 Charts are managed by an in-cluster API server, called Tiller. This makes many things (e.g., RBAC) harder, because the API server is run with a single ServiceAccount, which typically has global read/write access to the cluster.

  Pulumi requires no server-side component.

• The Pulumi CLI presents information-rich status updates, clearly showing progress as resources come online.

• Pulumi allows you to preview the effects a change will have on your resource configuration.

• Pulumi provides full lifecycle management (creation, deletion, replacement) of resources. If we must change an immutable field in an API object, pulumi preview alerts the user the object must be replaced.

• Helm 2 parameterizes YAML templates using Go templates, a textual replacement engine. Go templates are not guaranteed to generate syntactically-correct YAML. Pulumi exposes a rich, multi-language SDK, with strong typing to catch errors, and a pre-deployment validation step to catch errors before you run the program.

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.

Examples

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.