Pulumi Blog: Eron Wright

Pulumi Kubernetes Operator v2.3.0: Preview Mode and Structured Configuration

Eron Wright — Tue, 25 Nov 2025 00:00:00 +0000

We’re excited to announce the release of Pulumi Kubernetes Operator v2.3.0, introducing two powerful capabilities that enhance GitOps workflows: preview mode for validating infrastructure changes before deployment, and structured configuration support for managing complex data types. Building on the success of the v2.0 GA release, this update addresses long-standing community requests while maintaining full backwards compatibility. These features enable safer, more sophisticated infrastructure management patterns for platform engineering teams.

Preview mode: Validate infrastructure changes before deployment

Preview mode enables you to run Pulumi stacks in dry-run fashion, allowing you to visualize what infrastructure changes would occur without actually applying them. This capability is essential for GitOps workflows that require validation gates and incremental rollouts.

By adding preview: true to your Stack specification, the operator runs pulumi preview instead of pulumi up. The Stack’s Ready condition indicates preview success, and you get full status including preview links, standard output, and program outputs—all without making actual infrastructure changes.

This unlocks sophisticated workflow patterns:

Multiple Stacks for what-if analysis: Create several Stack resources pointing to the same Pulumi stack, with all-but-one operating in preview mode to compare different configurations
Branch validation: Preview changes from feature branches before merging to production
Tick-tock rollout patterns: Toggle the preview flag on and off with external verification steps between each deployment phase

Here’s a simple example showing a production stack alongside its preview counterpart:

# Production stack
apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: my-infrastructure
spec:
 stack: org/project/prod
 projectRepo: https://github.com/example/infra
 branch: main
---
# Preview stack - same Pulumi stack, preview mode
apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: my-infrastructure-preview
spec:
 stack: org/project/prod
 projectRepo: https://github.com/example/infra
 branch: feature-branch
 preview: true # Only runs pulumi preview

Preview mode closes issue #16, one of our longest-standing feature requests.

Structured configuration: Native support for complex data types

Configuration management takes a significant step forward with native support for complex data types. Previously limited to string values, Stack configuration now supports objects, arrays, numbers, and booleans as first-class citizens.

This enhancement addresses the reality that complex environments require rich configuration. You can now express sophisticated configuration structures inline in your Stack manifests or load them from ConfigMaps with automatic JSON parsing—all using Kubernetes-native patterns.

The implementation leverages Pulumi CLI’s JSON configuration support (available in v3.202.0+) with automatic version detection. If your workspace uses an earlier CLI version, you’ll receive clear guidance to upgrade. Existing string-only configurations continue to work without modification, ensuring full backwards compatibility.

Here’s an example of inline structured configuration:

apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: my-app
spec:
 stack: org/app/prod
 projectRepo: https://github.com/example/app
 branch: main
 config:
 # String values (existing behavior)
 environment: "production"

 # Objects (NEW)
 database:
 host: "db.example.com"
 port: 5432
 ssl: true

 # Arrays (NEW)
 regions: ["us-west-2", "us-east-1", "eu-west-1"]

 # Numbers and booleans (NEW)
 maxConnections: 100
 enableCaching: true

You can also reference ConfigMaps for more complex scenarios:

apiVersion: v1
kind: ConfigMap
metadata:
 name: app-settings
data:
 database.json: |
 {
 "host": "db.example.com",
 "port": 5432,
 "maxConnections": 100
 }
---
apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: my-app
spec:
 stack: org/app/prod
 projectRepo: https://github.com/example/app
 branch: main
 configRefs:
 database:
 name: app-settings
 key: database.json
 json: true # Parse as JSON

Note that Secrets are not a supported source of structured configuration values.

Structured configuration closes issue #258 and issue #872, addressing long-standing configuration management needs from the community.

Bug fixes and reliability improvements

This release includes several fixes that improve operational reliability:

Stack name validation: Added validation to limit Stack names to 42 characters, preventing resource naming conflicts (#899)
secretsProvider fix: The secretsProvider parameter now properly applies when creating new stacks (#935)
Helm chart fix: Resolved YAML parsing errors for podLabels containing special characters like colons (#1014)
Stack deletion: Stack deletion is no longer blocked when prerequisite stacks are missing, enabling proper cleanup workflows (#751)
Update TTL: Completed Update objects now respect the ttlAfterCompleted setting for automatic garbage collection (#960)

Upgrading to v2.3.0

This release includes updates to the Custom Resource Definitions (CRDs) to support the new features. If you’re using Helm, you’ll need to manually apply the updated CRDs before upgrading, as Helm v3 does not automatically upgrade CRDs:

# Apply updated CRDs
kubectl apply --server-side -k 'github.com/pulumi/pulumi-kubernetes-operator//operator/config/crd?ref=v2.3.0'

# Upgrade via Helm
helm upgrade pulumi-kubernetes-operator \
 oci://ghcr.io/pulumi/helm-charts/pulumi-kubernetes-operator \
 --version 2.3.0 \
 -n pulumi-kubernetes-operator

If you’re using the quickstart YAML installation method, the CRDs will update automatically when you apply the new manifest.

All changes are backwards compatible—existing Stack resources work without modification. For structured configuration support, ensure your workspace pods use Pulumi CLI v3.202.0 or later; the operator provides automatic version detection with clear upgrade guidance when needed.

Get started today

The v2.3.0 release enhances the Pulumi Kubernetes Operator with safer deployment workflows and more flexible configuration management. Preview mode enables validation-first GitOps patterns, while structured configuration simplifies complex multi-environment setups.

Get started with the Pulumi Kubernetes Operator in our documentation, or view the complete v2.3.0 release notes on GitHub. Join the conversation in the Pulumi Community Slack #kubernetes channel—we’d love to hear how these features impact your workflows.

Azure Native 3.8: Unified Credentials and Private Clouds

Eron Wright — Thu, 04 Sep 2025 12:00:00 -0700

Today we’re excited to announce Azure Native Provider v3.8, featuring several enhancements that simplify authentication and extend support to private Azure environments. These updates make it easier than ever to manage Azure infrastructure using credentials provided by the hosting environment, such as in Azure Kubernetes Service (AKS), Azure VM, and Azure Cloud Shell.

Simplified Authentication Across Environments

The highlight of this release is a new authentication mode based on DefaultAzureCredential, a feature of the Azure SDK that unifies authentication-related settings across deployment environments.

What’s New

DefaultAzureCredential automatically discovers and uses the best available authentication method for your environment, eliminating the need for an environment-specific configuration. It follows the Azure SDK’s standard credential chain:

Order	Credential	Description
1	Environment	Reads environment variables (e.g., `AZURE_TENANT_ID`, `AZURE_CLIENT_ID`) to authenticate as a service principal.
2	Workload Identity	For programs run on an Azure Kubernetes Service (AKS) cluster.
3	Managed Identity	For programs deployed to an Azure compute resource (e.g., Azure Virtual Machines) or App hosting platform.
4	Azure CLI	For local development using Azure CLI’s `az login` command.
5	Azure Developer CLI	For local development using Azure Developer CLI’s `azd auth login` command.

Real-World Benefits

This means your Pulumi programs can now run seamlessly across:

Local development machines using Azure CLI credentials
CI/CD pipelines with service principals via environment variables
Azure Kubernetes Service with Workload Identity
Azure VMs and App Services with Managed Identity

All without changing a single line of configuration code.

Getting Started

Enable DefaultAzureCredential using Pulumi configuration:

pulumi config set azure-native:useDefaultAzureCredential true
pulumi config set azure-native:subscriptionId <your-subscription-id>

Note that subscriptionId is a required configuration setting in this (and most) authentication modes; it ensures your resources are deployed to the correct Azure subscription.

Private Azure Cloud Support

This release brings improved support for Azure private clouds. A private cloud is a dedicated cloud computing environment used by a single organization.

The provider can now automatically discover, and configure itself for, any Azure cloud based on the ARM_METADATA_HOSTNAME environment variable. Note that this takes precedence over the ARM_ENVIRONMENT variable.

How To Use

The provider can query the Azure metadata service to automatically configure itself for your specific Azure environment:

# Using environment variable
export ARM_METADATA_HOSTNAME=management.azure.example

# Or via Pulumi configuration
pulumi config set azure-native:metadataHost management.azure.example

The provider expects the 2022-09-01 metadata schema, which resembles:

{
 "authentication": {
 "loginEndpoint": "https://login.microsoftonline.com",
 "audiences": [
 "https://management.core.windows.net/",
 "https://management.azure.com/"
 ]
 },
 "name": "AzureCloud",
 "suffixes": {
 "keyVaultDns": "vault.azure.net",
 "storage": "core.windows.net"
 },
 "resourceManager": "https://management.azure.com/",
 "microsoftGraphResourceId": "https://graph.microsoft.com/"
}

The provider automatically retrieves the correct endpoints for authentication, resource management, and other services.

Disabling Instance Discovery

Also in this release is a new setting, disableInstanceDiscovery, to determine whether the provider requests Microsoft Entra instance metadata from the login endpoint (https://login.microsoftonline.com) before authenticating. This setting is for Pulumi programs authenticating in disconnected clouds or private clouds.

Setting disableInstanceDiscovery to true will completely disable both instance discovery and authority validation. Please ensure that the configured authority host is valid and trustworthy.

How To Use

The provider can be configured to disable instance discovery:

# Using environment variable
export ARM_DISABLE_INSTANCE_DISCOVERY=true

# Or via Pulumi configuration
pulumi config set azure-native:disableInstanceDiscovery true

Authentication in AKS with Workload Identity

For programs run in a pod on an Azure Kubernetes Service (AKS) cluster, DefaultAzureCredential automatically uses the workload identity of the pod’s service account. This workload identity could then be granted roles in Azure to deploy stack resources.

Ensure that the application pods using workload identity include the label azure.workload.identity/use: "true" in the pod spec.

Walkthrough

Let’s use Pulumi Kubernetes Operator (PKO) to demonstrate a use case where you’d run Pulumi deployment operations in a pod and could benefit from workload identity.

The operator allocates a dedicated pod for each Pulumi stack under its management, to serve as the execution environment for stack operations. Each stack may use the same or a different service account. With AKS, that service account has a workload identity that providers may use to authenticate to Azure cloud and even to Pulumi cloud.

Create an AKS Cluster

Please follow the steps in “Deploy and configure workload identity on an Azure Kubernetes Service (AKS) cluster” to create an AKS cluster, managed identity, and Kubernetes service account. Those steps are:

You now have an Azure managed identity and associated Kubernetes service account that DefaultAzureCredential can use to authenticate to Azure cloud.

Take note of the clientId that represents the managed identity:

az identity show --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --query clientId
"c2bbe0f5-6349-480a-9f6f-3a5cb3e4ecf9"

Install the Pulumi Kubernetes Operator

Install the operator into the pulumi-kubernetes-operator namespace:

kubectl apply -f https://raw.githubusercontent.com/pulumi/pulumi-kubernetes-operator/refs/tags/v2.0.0/deploy/quickstart/install.yaml

Configure a Pulumi Cloud Access Token

By default, the operator uses Pulumi Cloud as the state backend for your stacks. Please create a Secret containing a Pulumi access token to be used to authenticate to Pulumi Cloud. Follow these instructions to create a personal, organization, or team access token.

kubectl create secret generic -n ${SERVICE_ACCOUNT_NAMESPACE} pulumi-api-secret --from-literal=accessToken=${PULUMI_ACCESS_TOKEN}

Update the Kubernetes Service Account

To use the service account that was created earlier, we need to grant it the system:auth-delegator role:

cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: "${SERVICE_ACCOUNT_NAMESPACE}-${SERVICE_ACCOUNT_NAME}:system:auth-delegator"
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: system:auth-delegator
subjects:
- kind: ServiceAccount
 name: "${SERVICE_ACCOUNT_NAME}"
 namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
EOF

Define an Example Program

Let’s define a simple Pulumi program that uses Azure Native 3.8 and calls the “getClientConfig” function to access the current identity of the provider.

cat <<"EOF" | kubectl apply -n ${SERVICE_ACCOUNT_NAMESPACE} -f -
apiVersion: pulumi.com/v1
kind: Program
metadata:
 name: sample-workload-identity
program:
 variables:
 clientConfig:
 fn::invoke:
 function: azure-native:authorization:getClientConfig
 clientToken:
 fn::secret:
 fn::invoke:
 function: azure-native:authorization:getClientToken
 outputs:
 clientConfig: ${clientConfig}
 clientToken: ${clientToken}
EOF

Run the Program using Workload Identity

Create a Stack object to run the Pulumi program using your service account and with azure-native:useDefaultAzureCredential enabled.

cat <<EOF | kubectl apply -f -
apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: sample-workload-identity
 namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
spec:
 programRef:
 name: sample-workload-identity
 stack: sample-workload-identity
 envRefs:
 PULUMI_ACCESS_TOKEN:
 type: Secret
 secret:
 name: pulumi-api-secret
 key: accessToken
 serviceAccountName: "${SERVICE_ACCOUNT_NAME}"
 config:
 azure-native:useDefaultAzureCredential: "true"
 azure-native:subscriptionId: "${SUBSCRIPTION}"
 workspaceTemplate:
 spec:
 podTemplate:
 metadata:
 labels:
 azure.workload.identity/use: "true"
EOF

Checking the stack outputs, we see a clientId matching that of the managed identity!

kubectl get stack/sample-workload-identity -oyaml

apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: sample-workload-identity
 namespace: default
status:
 conditions:
 - lastTransitionTime: "2025-09-04T23:32:11Z"
 message: the stack has been processed and is up to date
 reason: ProcessingCompleted
 status: "True"
 type: Ready
 outputs:
 clientConfig:
 clientId: c2bbe0f5-6349-480a-9f6f-3a5cb3e4ecf9
 objectId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 subscriptionId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 tenantId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 clientToken: '[secret]'

Conclusion

Azure Native Provider v3.8 represents our commitment to making Azure infrastructure management work seamlessly across all deployment scenarios, from local development to production, from public cloud to private cloud.

Have questions or feedback? Open an issue on GitHub or join the conversation in our Community Slack (#azure channel).

The Pulumi Go Provider SDK is Now Generally Available

Eron Wright — Tue, 20 May 2025 00:00:00 +0000

At Pulumi, we are committed to accelerating your cloud infrastructure journey by eliminating barriers between your teams and the tools they need. Today, we’re thrilled to announce a game-changing milestone that puts unprecedented power in your hands: the v1.0.0 release of the Pulumi Go Provider SDK!

Unlock the Full Potential of Your Cloud Ecosystem

The Pulumi Go Provider SDK v1.0 is a transformative framework that enables you to integrate any service, tool, or API into your infrastructure as code workflows. After extensive development since 2022 and battle-testing with enterprise customers, this framework is now stable and production-ready for your most critical infrastructure needs.

Pulumi has worked diligently to bring this SDK to maturity, incorporating feedback from enterprise users and leveraging it internally to build production providers like the Docker Build Provider. With v1.0.0, building robust, multi-language Pulumi providers is more accessible than ever.

Key Enhancements for Your Team

The Pulumi Go Provider SDK delivers capabilities that benefit everyone from platform engineers to DevOps professionals:

Go 1.24 Support: Utilize the latest language features and performance improvements
Intuitive Provider Builder API: A fluent, developer-friendly API that eliminates boilerplate and accelerates provider development
Functional-Style Components: Create reusable infrastructure building blocks with a natural, functional programming style
Enterprise-Grade Testing Framework: Ensure reliability with comprehensive testing capabilities for both resources and components

For a complete technical overview, see our comprehensive Pulumi Go Provider SDK documentation.

Defining and Testing a Custom Resource

Creating a Custom Resource in Minutes, Not Days

Let’s see how the SDK transforms the provider development experience. Using the infer package, you define your resource types using straightforward Go structs:

func main() {
 p.RunProvider("greetings", "0.1.0", provider())
}

func provider() p.Provider {
 p, _ := infer.NewProviderBuilder().
 WithResources(
 infer.Resource(&HelloWorld{}),
 ).
 Build()
 return p
}

// Each resource has a controlling struct.
type HelloWorld struct{}

// Each resource has in input struct, defining what arguments it accepts.
type HelloWorldArgs struct {
 Name string `pulumi:"name"`
 Loud *bool `pulumi:"loud,optional"`
}

// Each resource has a state, describing the fields that exist on the created resource.
type HelloWorldState struct {
 HelloWorldArgs
 Message string `pulumi:"message"`
}

func (l *HelloWorldState) Annotate(a infer.Annotator) {
 a.Describe(&l, "A Hello World resource")
 a.Describe(&l.Name, "Who to say hello to.")
 a.SetDefault(&l.Name, "user-")
 a.Describe(&l.Loud, "Indicates whether to give a LOUD greeting.")
 a.Describe(&l.Message, "The greeting message.")
}

You then implement the necessary methods for the resource’s lifecycle with surprising simplicity:

// All resources must implement Create at a minimum.
func (HelloWorld) Create(
 ctx context.Context, name string, input HelloWorldArgs, preview bool,
) (string, HelloWorldState, error) {
 state := HelloWorldState{HelloWorldArgs: input}
 if preview {
 return name, state, nil
 }
 state.Message = fmt.Sprintf("Hello, %s", input.Name)
 if input.Loud != nil && *input.Loud {
 state.Message = strings.ToUpper(state.Message)
 }
 return name, state, nil
}

This minimal code creates a fully-functional resource that your teams can use in their infrastructure code! The SDK handles all the complex gRPC communication with the Pulumi engine and automatically generates the necessary schema for multi-language support.

For detailed step-by-step instructions on building your own provider, check out our Build a Provider guide.

Confidence Through Comprehensive Testing

One of the biggest challenges with custom infrastructure providers is ensuring they’re reliable. The SDK’s built-in testing framework solves this with targeted capabilities:

Lifecycle Testing: Verify your resources’ CRUD operations function correctly
Component Testing: Validate complex resource compositions with mock capabilities
Integration Testing: Ensure your provider works seamlessly with the Pulumi ecosystem

Here’s how easy it is to test your custom resource:

func TestHelloWorldLifecycle(t *testing.T) {
 server, err := integration.NewServer(t.Context(), "greetings", semver.Version{Minor: 1},
 integration.WithProvider(provider()),
 )
 require.NoError(t, err)

 // Test the lifecycle methods of the HelloWorld resource.
 integration.LifeCycleTest{
 Resource: "pkg:index:HelloWorld",
 Create: integration.Operation{
 Inputs: property.NewMap(map[string]property.Value{
 "name": property.New("tester"),
 "loud", property.New(true),
 }),
 Hook: func(inputs, output property.Map) {
 message := output.Get("message").AsString()
 assert.Equal(t, "Hello, tester", message)
 },
 },
 }.Run(t, server)
}

For more information, see Pulumi Go Provider SDK.

Standardize Infrastructure with Powerful Component Resources

Beyond simple resources, providers can also define Component Resources. Components are higher-level abstractions that encapsulate multiple child resources working together to implement a specific capability. They are perfect for codifying organizational standards and best practices into reusable (cross-language!) building blocks.

The Pulumi Go Provider SDK introduces support for defining components using a functional style, similar to how you might define a local component within a single program. This provides a streamlined way to build components. Here’s an example using the functional style:

func provider() p.Provider {
 p, _ := infer.NewProviderBuilder().
 WithComponents(
 infer.ComponentF(NewRandomLogin),
 ).
 Build()
 return p
}

type RandomLoginArgs struct {
 Prefix pulumi.StringInput `pulumi:"prefix"`
}

type RandomLogin struct {
 pulumi.ResourceState
 RandomLoginArgs

 Username pulumi.StringOutput `pulumi:"username"`
 Password pulumi.StringOutput `pulumi:"password"`
}

func NewRandomLogin(ctx *pulumi.Context, name string, args RandomLoginArgs, opts ...pulumi.ResourceOption) (*RandomLogin, error) {
 comp := &RandomLogin{}
 err := ctx.RegisterComponentResource(p.GetTypeToken(ctx), name, comp, opts...)
 if err != nil {
 return nil, err
 }

 username, err := random.NewRandomPet(ctx, name+"-username", &random.RandomPetArgs{
 Prefix: args.Prefix,
 }, pulumi.Parent(comp))
 if err != nil {
 return nil, err
 }
 comp.Username = username.ID().ToStringOutput()

 password, err := random.NewRandomPassword(ctx, name+"-password", &random.RandomPasswordArgs{
 Length: pulumi.Int(12),
 }, pulumi.Parent(comp))
 if err != nil {
 return nil, err
 }
 comp.Password = password.Result

 return comp, nil
}

func (l *RandomLogin) Annotate(a infer.Annotator) {
 a.Describe(&l, "Generate a random login credential (a username and password).")
 a.Describe(&l.Prefix, "An optional prefix for the generated username.")
 a.SetDefault(&l.Prefix, "user-")
}

For a deep dive into creating component resources, see our comprehensive Build a Component guide.

And testing components is equally straightforward:

func TestRandomLogin(t *testing.T) {
 provider, err := provider()
 require.NoError(t, err)
 server, err := integration.NewServer(t.Context(),
 "random-login",
 semver.Version{Minor: 1},
 integration.WithProvider(provider),
 integration.WithMocks(&integration.MockResourceMonitor{
 NewResourceF: func(args integration.MockResourceArgs) (string, property.Map, error) {
 switch {
 case args.TypeToken == "random:index/randomPet:RandomPet" && args.Name == "login-username":
 assert.Equal(t, "foo", args.Inputs.Get("prefix").AsString())
 return "user", property.Map{}, nil

 case args.TypeToken == "random:index/randomPassword:RandomPassword" && args.Name == "login-password":
 assert.Equal(t, 12.0, args.Inputs.Get("length").AsNumber())
 return args.Name, property.NewMap(map[string]property.Value{
 "result": property.New("12345").WithSecret(true),
 }), nil

 return "", property.Map{}, nil
 },
 }),
 )
 require.NoError(t, err)

 // test the "random-login:RandomLogin" component
 resp, err := server.Construct(p.ConstructRequest{
 Urn: "urn:pulumi:stack::project::random-login:index:RandomLogin::login",
 Inputs: property.NewMap(map[string]property.Value{
 "prefix": property.New("foo"),
 }),
 })
 require.NoError(t, err)

 require.Equal(t, property.NewMap(map[string]property.Value{
 "username": property.New("user"),
 "password": property.New("12345").WithSecret(true),
 }), resp.State)
}

For more information about component resources, see the blog post Announcing the Next-Generation of Pulumi Components: Enabling Infrastructure Abstractions.

A major advantage of using the Pulumi Go Provider SDK is that your provider, once written in Go, can be used in any Pulumi program, in any supported language (TypeScript, Python, Go, .NET, Java, or YAML). The SDK’s automatic schema generation takes care of creating the necessary language-specific SDKs, enabling cross-language consumption without manual effort.

Packaging and publishing your provider for others to use, whether within your organization or publicly, is a key step. Follow our Publishing Packages guide for detailed instructions on distributing your custom provider.

Understanding Provider Schema

The SDK automatically generates a schema for your provider based on the Go types and annotations you define. This schema describes the resources, their inputs and outputs, and documentation. For more details on how schema generation works and how to customize it, check out our Schema documentation.

Get Started Today!

The release of the Pulumi Go Provider SDK represents a significant step forward in simplifying and accelerating the development of Pulumi providers. By focusing on a code-first approach, automatic schema generation, and providing a robust testing framework, we are empowering engineers to integrate Pulumi with virtually any service or tool.

We encourage you to explore the Pulumi Go Provider SDK, build your own integrations, and contribute to the growing ecosystem of Pulumi providers. Start with our Extending Pulumi overview documentation to get a complete picture of the possibilities.

Explore our documentation on Extending Pulumi
Review examples in the GitHub repository
Learn how to build a provider with our step-by-step guide
Identify your first integration - what custom service would provide the most value to your team?
Join our community in the Pulumi Community Slack to learn from others building custom providers
Share your feedback with us on the in Slack or by opening an issue in the pulumi/pulumi-go-provider GitHub repository.

Happy building!

Pulumi Kubernetes Operator 2.0 is Now Generally Available!

Eron Wright — Thu, 20 Feb 2025 00:00:00 +0000

Today marks an exciting milestone as we announce the General Availability (GA) release of the Pulumi Kubernetes Operator 2.0! This release builds upon the foundation we laid during the beta phase, delivering a production-ready solution that transforms how teams manage their cloud infrastructure.

Learn more about the Pulumi Kubernetes Operator in our documentation

What Is the Pulumi Kubernetes Operator?

The Pulumi Kubernetes Operator brings infrastructure automation directly to your Kubernetes cluster. By treating your infrastructure as native Kubernetes resources, it enables teams to manage their entire cloud environment—from databases to DNS records—using familiar Kubernetes workflows and tools.

Imagine having a dedicated infrastructure automation engine running within your cluster, continuously ensuring your cloud resources stay in sync with your desired state. That’s exactly what the Pulumi Kubernetes Operator delivers, complete with the observability and control you need for production environments.

The Evolution to 2.0

Pulumi Kubernetes Operator 2.0 introduces a completely new architecture for running Pulumi programs. The key changes include:

Each Stack now runs in its own dedicated Workspace pod, rather than within the Operator pod
A new Workspace custom resource manages the Workspace pod lifecycle
Stack operations are coordinated through a new Update custom resource
The Stack custom resource API remains the primary interface, maintaining backward compatibility

This architecture delivers improved resource isolation, better secrets management, and flexible Workspace customization options. The pod-per-stack model ensures reliable resource allocation and clear operational boundaries for each deployment.

What’s New in GA?

The GA release introduces three powerful capabilities that give you more control over your deployments:

Enhanced Logging Control

You can now set the log verbosity level of the Pulumi CLI for any given stack or Workspace. This feature offers granular control over logging output, making debugging and fine-tuning your deployment process more efficient.

New Controller Events for Better Instrumentation

Additional controller events have been introduced to provide richer instrumentation and observability. These events offer improved insights into the operator’s behavior, enabling more effective monitoring of your infrastructure.

Workspace Reclaim Policy

Managing Workspace lifecycles is now even more flexible with the new workspaceReclaimPolicy field in the Stack specification. This enhancement allows you to define how workspace resources should be handled after stack deployment. The supported policies are:

Retain: Keeps the Workspace and its resources after deployment (default)
Delete: Automatically removes the Workspace once the stack is fully deployed

This gives you fine-grained control over resource cleanup and helps prevent workspace sprawl in your cluster.

See It in Action

Here’s an example that demonstrates how to deploy a Pulumi stack using the operator. This configuration creates a service account with appropriate permissions and defines a Stack resource that deploys a sample project from the Pulumi examples repository:

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

// Create a Kubernetes ServiceAccount for the Pulumi Workspace pod
const sa = new k8s.core.v1.ServiceAccount("random-yaml", {});

// Grant system:auth-delegator to the ServiceAccount
const crb = new k8s.rbac.v1.ClusterRoleBinding("random-yaml:system:auth-delegator", {
 roleRef: {
 apiGroup: "rbac.authorization.k8s.io",
 kind: "ClusterRole",
 name: "system:auth-delegator",
 },
 subjects: [{
 kind: "ServiceAccount",
 name: sa.metadata.name,
 namespace: sa.metadata.namespace,
 }],
});

// Provision a Pulumi Cloud access token and store it in a Kubernetes Secret
const accessToken = new pulumiservice.AccessToken("random-yaml", {
 description: `For stack "${pulumi.runtime.getOrganization()}/${pulumi.runtime.getProject()}/${pulumi.runtime.getStack()}"`,
});
const apiSecret = new k8s.core.v1.Secret("random-yaml", {
 stringData: {
 "accessToken": accessToken.value,
 }
});

// Deploy the "random-yaml" program from the github.com/pulumi/examples repository.
const stack = new k8s.apiextensions.CustomResource("random-yaml", {
 apiVersion: 'pulumi.com/v1',
 kind: 'Stack',
 spec: {
 serviceAccountName: sa.metadata.name,
 projectRepo: "https://github.com/pulumi/examples",
 repoDir: "random-yaml/",
 branch: "master",
 shallow: true,
 stack: "pulumi-ts",
 refresh: true,
 destroyOnFinalize: true,
 envRefs: {
 PULUMI_ACCESS_TOKEN: {
 type: "Secret",
 secret: {
 name: apiSecret.metadata.name,
 key: "accessToken",
 },
 },
 },
 workspaceTemplate: {
 spec: {
 image: "pulumi/pulumi:3.147.0-nonroot",
 },
 },
 },
}, {dependsOn: [sa, crb, apiSecret]});

Here’s an example of the enhanced event stream that shows the lifecycle of a stack deployment, from workspace creation to successful completion:

88s Normal SuccessfulCreate statefulset/random-yaml-09aa1aad-workspace create Pod random-yaml-09aa1aad-workspace-0 in StatefulSet random-yaml-09aa1aad-workspace successful
88s Normal StackUpdateDetected stack/random-yaml-09aa1aad Initial stack update
0s Normal Pulled pod/random-yaml-09aa1aad-workspace-0 Container image "pulumi/pulumi:3.147.0-nonroot" already present on machine
0s Normal Created pod/random-yaml-09aa1aad-workspace-0 Created container pulumi
0s Normal Started pod/random-yaml-09aa1aad-workspace-0 Started container pulumi
0s Normal Initialized workspace/random-yaml-09aa1aad Initialized workspace pod "random-yaml-09aa1aad-workspace-0"
0s Normal StackUpdateDetected stack/random-yaml-09aa1aad Initial stack update
0s Normal UpdateSucceeded update/random-yaml-09aa1aad-195200641a9 Updated stack "pulumi-ts"
0s Normal StackCreated stack/random-yaml-09aa1aad Successfully updated stack

Additional Resources

To help you get the most out of Pulumi Kubernetes Operator 2.0, we’ve prepared comprehensive documentation:

Migration Guide: Step-by-step instructions for upgrading from v1.x to v2.0
Troubleshooting Guide: Common issues and their solutions
Release Notes: Full details of what’s new in version 2.0

Start Using It Today

We are excited to see how you will use these new features to transform your cloud operations. Share your experiences, questions, and insights with us through our community forums or Slack channel.

Get started with the Pulumi Kubernetes Operator in our documentation

Happy deploying!

Pulumi Copilot is Now Available in VS Code

Meagan Cojocar — Mon, 03 Feb 2025 00:00:00 +0000

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. The Pulumi Copilot Chat extension for VS Code is deprecated — instead, run Neo directly in your editor via the Agent Client Protocol.

Programming languages offer dozens of advantages for writing Infrastructure as Code (IaC). One of them is that Large Language Models are effective at using general-purpose programming languages, thanks to the vast amount of high-quality training data available. Building on this advantage, we introduced Pulumi AI and Pulumi Copilot last year to enhance Infrastructure-as-Code development with generative AI capabilities. These tools have significantly streamlined infrastructure deployment for tens of thousands of developers.

Today, we are thrilled to announce that Pulumi Copilot is now available directly within Pulumi Copilot Chat Extension. By simply typing @pulumi in Copilot Chat, developers can now access the power of Pulumi Copilot right within their IDE, saving them time on writing IaC and getting infrastructure deployed.

Video Walk Through

Hear Adam and Eron from Pulumi walk through this new feature in our PulumiTV introduction to the Visual Studio Code extension.

What is Pulumi Copilot?

Pulumi Copilot is an AI-powered conversational assistant that seamlessly integrates with Pulumi Cloud, helping users:

Explore and manage cloud infrastructure
Gain insights into resources, policies, and deployments
Troubleshoot errors and optimize configurations
Author and deploy Pulumi IaC more effectively

Pulumi Copilot combines industry-leading AI models with Pulumi specific knowledge like the latest versions of providers, IaC best practices, and context from Pulumi Cloud on your environment.

The Pulumi Copilot REST API

The Pulumi Tools Visual Studio Code extension is powered by the recently announced Pulumi Copilot REST API, which enables developers to integrate Pulumi Copilot’s capabilities into their own tools and platforms. Just as we’ve built this extension to bring Pulumi Copilot directly into your development environment, you can use the same REST API to create your own innovative integrations, whether that’s a custom CLI tool, a chat bot, or another IDE extension. The API’s support for multi-turn conversations and contextual understanding makes it possible to build rich, interactive experiences like the one we’re delivering today.

How to Use Pulumi Copilot in Visual Studio Code

Using Pulumi Copilot in Visual Studio Code (VS Code) is as simple as 1-2-3:

Install the Pulumi VS Code extension
Open VS Code and navigate to Copilot Chat (icon to the right of the search bar)
Type @pulumi to activate Pulumi Copilot

You can then ask questions about your infrastructure, generate code, check deployment status, debug Pulumi errors, and more.

This seamless integration brings Pulumi’s intelligence directly into the developer workflow.

Pulumi Copilot respects all role-based access control (RBAC) settings in Pulumi Cloud, ensuring that AI-generated responses are scoped only to authorized users within an organization.

Key Use Cases

Let’s explore four powerful ways to use Pulumi Copilot in VS Code:

Infrastructure Code Generation

With Pulumi Copilot in VS Code, developers can generate Pulumi programs for new use cases, solving the blank page problem and getting you from 0 to 0.9.

Simply describe what you want to build and Pulumi Copilot will generate the infrastructure code for you. For example, ask “Create an AWS S3 bucket with versioning enabled and encrypted with a KMS key” and Copilot will generate the complete Pulumi program. Or ask Pulumi Copilot to extend an existing project such as adding a ManagedNodeGroup to your AWS EKS cluster.

Terraform to Pulumi Migration

Migrating from Terraform to Pulumi? Just point Copilot at your Terraform files and ask it to convert them. For example:

Open your main.tf file in VS Code
Type @pulumi convert this Terraform configuration to TypeScript
Copilot will analyze your Terraform code and generate equivalent Pulumi code in index.ts

The conversion maintains your existing resource configurations while taking advantage of Pulumi’s native programming language features.

Resource Discovery

Pulumi Copilot can search across your entire infrastructure to find resource usage patterns. Ask questions like “Do we use AWS Lambda functions in any other stacks?” or “Show me all S3 buckets with public access enabled.” Copilot will search your codebase and Pulumi Cloud to provide comprehensive answers about your infrastructure.

Error Resolution

When you encounter errors in the terminal during Pulumi operations, Copilot can help explain and resolve them. Simply copy the error message and ask Copilot to explain it. For example:

Error: Error creating S3 Bucket (my-bucket): BucketAlreadyExists: The requested bucket name is not available

Copilot will explain the error in plain language, suggest potential solutions, provide code examples for fixing the issue, and reference similar issues from your organization’s history.

Getting Started

Pulumi Copilot is free to use for all organizations in Pulumi Cloud. Organization administrators can enable Pulumi Copilot by navigating to: Settings > Access Management > Pulumi Copilot in the Pulumi Cloud console.

Try it now in VS Code and experience AI-driven cloud infrastructure management right in your IDE.

👉 Start Using Pulumi Copilot 👉 Start Using Pulumi Copilot in Visual Studio Code

We can’t wait to see what you build with Pulumi Copilot! 🚀

Pulumi Kubernetes Operator 2.0

Eron Wright — Fri, 18 Oct 2024 00:00:00 +0000

Update: “Pulumi Kubernetes Operator 2.0 is Now Generally Available!”

A few years ago we released the Pulumi Kubernetes Operator, a cloud-native way to manage and deploy cloud infrastructure using Pulumi from within your Kubernetes environment. We’ve heard your feedback about limitations related to scalability and isolation. Today, we’re excited to announce a preview release of version v2.0 of the Pulumi Kubernetes Operator. We’ve put a new, horizontally scalable architecture in place along with a variety of new security features and customization options. Let’s dig in!

What is the Pulumi Kubernetes Operator?

The Pulumi Kubernetes Operator defines a Kubernetes Custom Resource called pulumi.com/v1/Stack, which represents a Pulumi stack. The Pulumi stack can be authored in any supported Pulumi language (TypeScript, Python, Go, .NET, Java, YAML) and can deploy and manage cloud infrastructure in any supported cloud (AWS, Azure, GCP, Kubernetes and 60+ additional cloud and SaaS providers). The Pulumi Kubernetes Operator triggers cloud deployments based on changes to the Stack Custom Resource or the resources it uses.

As a result, the Pulumi Kubernetes Operator enables users to specify the desired state of their cloud infrastructure by using resources managed directly in their Kubernetes cluster. Modifying those Kubernetes resources will trigger creation, updates, and deletion of the underlying cloud infrastructure that they manage.

For example, the Operator can use the Stack resource below to run a Pulumi program, as defined in a GitHub repository, to deploy NGINX. Subsequent commits to the repository, or changes to the stack’s configuration, will cause the Operator to re-deploy the infrastructure.

apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: nginx-k8s-stack-production
spec:
 stack: acmecorp/nginx/production
 projectRepo: https://github.com/acmecorp/pulumi-nginx
 commit: 2b0889718d3e63feeb6079ccd5e4488d8601e353

The Pulumi Kubernetes Operator can also be used along with Pulumi’s Kubernetes Provider, which allows Pulumi programs to deploy resources to Kubernetes – either in the same cluster as the Operator, or in another cluster. This can be used to package up complex Kubernetes infrastructure into more abstracted units, to mix Kubernetes and cloud infrastructure into a single unit of deployment, to define how application workloads are deployed into a cluster, or for a wide variety of other use cases. The Pulumi Kubernetes Provider has full support for the Kubernetes API available in every Pulumi language, including support for Helm.

What’s New in Pulumi Kubernetes Operator 2.0?

The 2.0 release is based on a whole new architecture for running Pulumi programs in your Kubernetes cluster. The Operator now allocates a dedicated pod for each Stack to serve as the execution environment for Pulumi stack operations. Previously, all stack operations took place within the Operator’s own pod. This new approach effectively isolates each stack’s compute and memory resources, improves the isolation of secrets, and opens up new customization options.

These pods are referred to as workspace pods. Under the hood, a new Workspace Custom Resource handles the lifecycle of the workspace pod, and is created automatically by the system. A related Update Custom Resource applies a stack operation to a given workspace.

The Stack Custom Resource is still the primary API for using the Pulumi Kubernetes Operator and is largely unchanged. See the Migration section below to understand how to prepare your Stack objects for use with the 2.0 release.

Note: a key limitation of the new system is that cross-namespace references are strictly forbidden. For example, a Stack cannot refer to a Secret in another namespace.

Installation

With the 2.0 release, the supported installation modes are limited to a cluster-wide installation. You’ll need to be a cluster admin to install the Operator. The Operator is able to handle stacks across all the namespaces of your cluster.

We provide three ways to install the Operator:

a Pulumi program (see: deploy/pulumi-operator-yaml/)
a Helm chart (see: deploy/helm/pulumi-operator/)
a simple manifest file for dev environments (see: deploy/quickstart/install.yaml)

Please uninstall any earlier version of the Pulumi Kubernetes Operator, then install the new version using one of the above options. Note that this will remove any existing Stack objects in your cluster, so be sure to export their manifests or have a way to restore them.

Security

To protect your Kubernetes cluster, workspace pods are configured to have minimal permissions as defined by the ‘restricted’ profile of the Pod Security Standards. If necessary, you may configure a stack to use the ‘baseline’ profile.

A Kubernetes ServiceAccount provides an identity for your workspace pod, and we recommend that you create a service account for your stack rather than using the default account. If your Pulumi program uses the Kubernetes provider to manage resources within the cluster, the stack’s service account will need permissions, e.g. a RoleBinding to the ClusterRole named cluster-admin. See “Service Accounts” for more information.

The workspace pod has a RPC endpoint that is used by the Operator to run stack operations. The pod protects the RPC endpoint using Kubernetes RBAC, and for that reason you must bind the ClusterRole named system:auth-delegator to the stack’s service account.

Scalability

Each stack is run in its own “workspace” pod, and so the system scales horizontally to support many stacks. The workspace pod is, by default, configured to use minimal resources when idle, and to ‘burst’ into the unused memory and compute resources of the node during a stack operation. You may customize the resource constraints to fit the needs of your stack by using the workspaceTemplate field. If your Kubernetes cluster has high utilization, we recommend increasing the resource requests and limits. See “Pod Quality of Service Classes” for more information.

Once a stack reaches its desired state, the workspace pod may be retained or deleted based on the workspaceReclaimPolicy field. The default behavior is to retain the workspace for subsequent updates. This feature enables you to make a trade-off decision between performance and efficiency.

Stability

A Kubernetes cluster is a dynamic environment where a given pod may be terminated at any time, e.g. due to maintenance operations, unplanned node events, or resource pressure. This can cause problems for ongoing stack operations, and historically may cause a stack to become “locked”, necessitating manual intervention with the use of pulumi cancel.

The new system has been made more resilient by being responsive to pod termination requests. It responds by proactively sending CTRL-C to the ongoing stack operation, to gracefully wind down the operation.

If your stack has a lot of resources, consider increasing the pod’s termination grace period (default: 10 minutes).

Customization and Extensibility

Let’s discuss how to customize the stack’s environment. The Stack resource continues to provide ways to set environment variables and to set stack configuration values. What’s new is the ability to:

use a custom Docker image for your stack environment
set the stack environment’s compute and storage resources
attach volumes, init containers, and sidecars

This is accomplished using the workspaceTemplate field of the Stack resource, to customize the Workspace object that is automatically created by the system for a given stack.

By default, the system uses the official pulumi/pulumi Docker image. You may wish to create your own Docker image that is based on it, e.g. to pre-install your program’s dependencies (using pulumi install) for performance reasons. Be prepared to update the image over time to incorporate the latest version of the Pulumi CLI.

One use case for an extra init container is to customize how your program’s sources are obtained. The system supports Git repositories and Flux sources out-of-the-box, but you have the option of handling it yourself, e.g. to generate a Pulumi project or to download from another source. You simply inject an init container, mount the share volume to /share, and then place the project files into /share/workspace. Contact us to learn more.

Here’s an example of a stack with some customizations applied:

apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: my-stack
spec:
 ...
 workspaceTemplate:
 spec:
 image: example/pulumi-with-dependencies:v3.334
 podTemplate:
 metadata:
 labels:
 example.com/mylabel: bar
 spec:
 terminationGracePeriodSeconds: 3600
 tolerations:
 - key: "example.com/foo"
 operator: "Exists"
 effect: "NoSchedule"
 initContainers:
 - name: extra # add an extra init container
 image: busybox
 command: ["sh", "-c", "echo 'Hello, extra init container!'"]
 securityContext:
 allowPrivilegeEscalation: false
 capabilities:
 add:
 - NET_BIND_SERVICE
 drop:
 - ALL
 volumeMounts:
 - name: share
 mountPath: /share
 containers:
 - name: pulumi # customize the main container where Pulumi stack operations are executed
 volumeMounts:
 - name: oidc-token
 mountPath: /var/run/secrets/pulumi
 volumes:
 - name: oidc-token # mount an OIDC token
 projected:
 sources:
 - serviceAccountToken:
 audience: urn:pulumi:org:ORG_NAME
 path: token
 expirationSeconds: 3600

Operability

Since each stack has its own long-running pod, you may inspect the console output for a given stack by accessing the pod logs. The pod’s name is based on the stack name; for example, given a stack named my-stack, look for a pod named my-stack-workspace-0. We recommend the stern tool to access pod logs. See “Pod and container logs” for more information.

If you need to run an interactive Pulumi command for your stack, e.g. pulumi import, exec into the workspace pod. Navigate to the /share/workspace directory and you should find your program there.

Use the spec.pulumiLogLevel field to increase the log verbosity level of the Pulumi CLI.

Walkthrough

Here’s a quick demonstration of the new system. Let’s deploy the random-yaml program from the pulumi/examples repository.

We’ll be using Flux for this demonstration; to follow along, install Flux (see “Installation”).

Setup the GitRepository Source

For this demonstration, we’ll use Flux to clone and cache the pulumi/examples repository, since it is a large repository and the Flux cache provides a big performance improvement. The system works well without Flux too.

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
 name: pulumi-examples
 namespace: default
spec:
 interval: 24h
 ref:
 branch: master
 url: https://github.com/pulumi/examples

Install a Pulumi Access Token

Create a Secret containing a Pulumi access token to be used by the stack to authenticate to Pulumi Cloud. Follow these instructions to create a personal, organization, or team access token.

Store the access token into a Kubernetes Secret. Here’s an easy way to create a Secret named pulumi-api-secret. Replace TOKEN with the token that you created.

$ kubectl create secret generic pulumi-api-secret -n default --from-literal=accessToken=TOKEN

Create a Service Account

The stack requires a Kubernetes service account with a binding to the system:auth-delegator cluster role.

If you don’t have admin permissions in your Kubernetes cluster, ask your administrator to create the service account for you. The Pulumi Kubernetes Operator installer also pre-creates a usable ServiceAccount named pulumi in the default namespace.

apiVersion: v1
kind: ServiceAccount
metadata:
 name: random-yaml
 namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: random-yaml:system:auth-delegator
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: system:auth-delegator
subjects:
- kind: ServiceAccount
 name: random-yaml
 namespace: default

Create the Stack

Let’s apply a Stack object to deploy the program. Note that the specification makes reference to the GitRepository (pulumi-examples), the Secret (pulumi-api-secret), and the ServiceAccount (random-yaml) created earlier.

apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: random-yaml
 namespace: default
spec:
 serviceAccountName: random-yaml
 fluxSource:
 sourceRef:
 apiVersion: source.toolkit.fluxcd.io/v1
 kind: GitRepository
 name: pulumi-examples
 dir: random-yaml/
 stack: dev
 refresh: true
 continueResyncOnCommitMatch: true
 resyncFrequencySeconds: 300
 destroyOnFinalize: true
 envRefs:
 PULUMI_ACCESS_TOKEN:
 type: Secret
 secret:
 name: pulumi-api-secret
 key: accessToken

This stack is configured to deploy immediately and to resync every five minutes. The term “resync” means to execute pulumi up, which is useful for stacks that produce resources or outputs that require a periodic update. Without resync, pulumi up runs whenever a new commit is pushed to the repository.

Observe the Workspace

The system automatically creates a Workspace object named random-yaml to provision an execution environment. Let’s watch as the workspace’s status progresses towards readiness. For this demonstration, we’ll use the --watch flag to observe the status updates:

$ kubectl get workspace --watch
NAME IMAGE READY ADDRESS
random-yaml pulumi/pulumi:3.134.1-nonroot
random-yaml pulumi/pulumi:3.134.1-nonroot False
random-yaml pulumi/pulumi:3.134.1-nonroot False random-yaml-workspace.default.svc.cluster.local:50051
random-yaml pulumi/pulumi:3.134.1-nonroot False random-yaml-workspace.default.svc.cluster.local:50051
random-yaml pulumi/pulumi:3.134.1-nonroot True random-yaml-workspace.default.svc.cluster.local:50051

Observe the Updates

Once the workspace is ready, the system proceeds to run a periodic update. Each update is represented by an Update object. Let’s watch the progression across three updates:

$ kubectl get update --watch
NAME WORKSPACE PROGRESSING FAILED COMPLETE URL
random-yaml-5kmn7dcm random-yaml
random-yaml-5kmn7dcm random-yaml True False False
random-yaml-5kmn7dcm random-yaml False False True https://app.pulumi.com/eron-pulumi-corp/random/dev/updates/1
random-yaml-rftp8gj8 random-yaml
random-yaml-rftp8gj8 random-yaml True False False
random-yaml-rftp8gj8 random-yaml False False True https://app.pulumi.com/eron-pulumi-corp/random/dev/updates/2
random-yaml-sjpw5hm8 random-yaml
random-yaml-sjpw5hm8 random-yaml True False False
random-yaml-sjpw5hm8 random-yaml False False True https://app.pulumi.com/eron-pulumi-corp/random/dev/updates/3

Observe the Stack

The Stack object maintains a status block showing the result of the latest attempt and whether an update is currently running. Taking a look, we see a successful outcome.

$ kubectl get stack random-yaml -oyaml

apiVersion: pulumi.com/v1
kind: Stack
...
status:
 conditions:
 - lastTransitionTime: "2024-10-17T20:41:49Z"
 message: the stack has been processed and is up to date
 reason: ProcessingCompleted
 status: "True"
 type: Ready
 lastUpdate:
 failures: 0
 generation: 2
 lastAttemptedCommit: sha256:44d554df090dcdeb9bae908cd38155c8c93db05f64dc72982027e8e1294af0d3
 lastResyncTime: "2024-10-17T20:41:49Z"
 lastSuccessfulCommit: sha256:44d554df090dcdeb9bae908cd38155c8c93db05f64dc72982027e8e1294af0d3
 name: random-yaml-sjpw5hm8
 permalink: https://app.pulumi.com/eron-pulumi-corp/random/dev/updates/3
 state: succeeded
 type: up
 observedGeneration: 2
 outputs:
 password: '[secret]'

Delete the Stack

To complete the demonstration, let’s delete the Stack object. Because spec.destroyOnFinalize is enabled, deleting the object causes the Pulumi stack to be destroyed. That is, the stack resources are deleted.

$ kubectl delete stack random-yaml
stack.pulumi.com "random-yaml" deleted

$ kubectl get workspace
No resources found in default namespace.

$ kubectl get update
No resources found in default namespace.

Run Pulumi inside your cluster

Use the Pulumi Kubernetes Operator to deploy and manage cloud infrastructure with the Stack custom resource, driven by the Git changes your cluster already watches.

Get started

Migration

Ready to leverage these new features? Let’s quickly cover how to migrate your existing setup to Pulumi Kubernetes Operator 2.0.

The Stack custom resource continues to be the primary way to use the Pulumi Kubernetes Operator, and your existing stack definitions should continue to work after you follow a simple migration procedure:

Create a ServiceAccount and associated ClusterRoleBinding as shown in the Security section.
If your stack uses the Pulumi Kubernetes Provider, create a RoleBinding or a ClusterRoleBinding to grant the necessary permissions, e.g. to the well-known ClusterRole named cluster-admin. See “Using RBAC Authorization” for more information.
Edit your Stack manifest(s) to use the service account, by setting the spec.serviceAccountName field.
Double-check that your Stack objects do not make use of cross-namespace references.

If you’re using a private Git repository as your program source, use the Stack’s secretRefs field to reference Git credentials. SSH-based access to the repository may require a custom image with your host’s public key(s) baked in. Contact us to learn more.

If you’re using Flux integration, there’s an additional step to be performed by your cluster administrator. Please create a NetworkPolicy to allow the workspace pods to access the Flux source controller. Here’s the manifest to be applied:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: allow-pulumi-fetch-flux-artifacts
 namespace: flux-system
spec:
 podSelector:
 matchLabels:
 app: source-controller
 ingress:
 - ports:
 - protocol: TCP
 port: http
 from:
 - namespaceSelector:
 matchLabels:
 kubernetes.io/metadata.name: default
 - podSelector:
 matchLabels:
 app.kubernetes.io/managed-by: pulumi-kubernetes-operator
 app.kubernetes.io/name: pulumi
 app.kubernetes.io/component: workspace
 policyTypes:
 - Ingress

Conclusion

The Pulumi Kubernetes Operator is a great way to deploy and manage cloud infrastructure from within your Kubernetes environment. With the 2.0 release, we’ve solved the scalability and isolation limitations that affected early adopters. You can get started with the Pulumi Kubernetes Operator today. Please join us on the #kubernetes channel of the Pulumi Community Slack workspace to give feedback, and enjoy!

Announcing the Pulumi Visual Studio Code Extension

Meagan Cojocar — Wed, 18 Sep 2024 08:56:00 +0000

At the heart of Pulumi’s approach to cloud infrastructure and secrets management is a belief in empowering engineers to use the best software engineering tools to manage complexity at scale and to be maximally productive building cloud infrastructure and applications for their businesses.

Today, we’re excited to announce a next big step in delivering great software engineering tools for Pulumi users, with the launch of a new Pulumi Visual Studio Code (VS Code) Extension. The Pulumi VS Code Extension brings Pulumi key features for Pulumi IaC and Pulumi ESC directly into the IDE environment that many Pulumi users work in every day. Pulumi IaC users can now debug their applications and get Pulumi YAML language support directly in VS Code. And Pulumi ESC users can now create and manage environments, secrets and configuration directly within the IDE with rich IDE features.

The following are a few examples of new capabilities available for Pulumi users in VS Code today:

Launch your Pulumi program under a debugger
Automatically generate a launch configuration for a Pulumi project
Create and explore Pulumi ESC (Environments, Secrets, and Configuration) environments
Get contextual warnings and errors directly within the editor for Pulumi YAML

Getting Started

Install the Software

Install Pulumi 3.132.0 (or greater) using these instructions.
Install the Pulumi VS Code extension from the Visual Studio Marketplace.

Debugging Pulumi IaC Programs

For simple Pulumi programs, it’s easy enough to see what will happen when you look at the IaC code. But as teams build more complex cloud infrastructure components, fully taking advantage of Pulumi’s support for all of the rich componentization and control flow features in their language of choice, it can become more challenging to diagnose why a particular input value is being used for a cloud infrastructure resource, and what set of decisions were made by the infrastructure components to arrive at that. The pulumi CLI recently added support for a new --attach-debugger flag, which allows attaching a debugger to any language processes that are run as part of a Pulumi operation - regardless of the language. We’ve now added native VS Code debugger extension support for it as well, so that you can debug your Pulumi programs in any language with just a couple of clicks.

Start Debugging

The Pulumi VS Code Extension allows you to run and debug Pulumi programs with ease. Open a new or existing Pulumi project in VS Code and use an automatic or customized launch configuration.

Select the Run and Debug icon.
Choose Show all automatic debug configurations.
Select “Pulumi…” then “pulumi preview” or “pulumi up”.

Pulumi automatically generates a debug configuration for the current stack, making it simple to get started. You can also set breakpoints in your program and use the full functionality of the VS Code debugger.

You can now step through your code, set breakpoints on resource constructors or inside apply callbacks, and see the callstack and the values of variables within the VS Code debugger.

Create a Launch Configuration

For more control, you can create a customized launch configuration:

Click the gear icon when selecting an automatic debug configuration to customize it.
Alternatively, create a launch.json file and use a configuration template.

You can run without debugging by selecting “Run Without Debugging” from the Run menu or by adding "noDebug": "true" to your configuration.

Using Pulumi ESC

Pulumi ESC manages secrets and configuration for your applications and infrastructure within a centralized and composable secrets store. The environments are stored securely within Pulumi Cloud, and can be edited and opened from the Pulumi Cloud console or from the pulumi CLI or REST API.

For developers working with both their application infrastructure code as well as their Pulumi ESC environments, it is convenient to be able to edit ESC environments and the secrets they contain directly within the IDE without switching contexts.

The Pulumi ESC integration in the Pulumi VS Code extensions makes this easy. You can navigate through your environments, see all the projects and versions, and directly edit the source of the environments within VS Code. When you save, the edit to the environment is saved directly back into Pulumi ESC as a new version. And while you have it open in VS Code, you get all the amazing software engineering productivity feature of your IDE - colorization, completion lists, error checking, goto definition, find references and much more!

Open the ESC Explorer

From the primary sidebar, open the “Pulumi ESC Explorer” view and click “Login” to authenticate to Pulumi Cloud. Once logged in, you’ll see a tree of your organizations and environments.

Key Capabilities

Easily create or edit environments by clicking the plus sign on an organization or project node. The extension opens an editor where you can define and save new environment revisions. The IntelliSense functionality will guide you on various values, such as completion for setting up provider configuration.

You can also:

Run your application in the context of your environment by hovering over it and selecting the terminal icon

Delete environments by hovering over them and selecting the delete icon
Decrypt environments for cloning or moving
View environment versions over time
Compare different environments or environment versions
Use the search icon to quickly find environments
Tag specific environment revisions for easy reference.

Manage infrastructure from your editor

Pulumi brings infrastructure as code and Pulumi ESC into the tools you already work in. Build, deploy, and debug your stacks, then manage secrets and configuration in Pulumi Cloud.

Get started

Pulumi YAML Support

Along with support for many popular programming languages including TypeScript, Python, Go, .NET and Java - Pulumi also supports a simple declarative YAML language for defining and managing infrastructure. VS Code already has great support for all the other languages Pulumi supports, but for Pulumi YAML, the Pulumi VS Code Extension offers great support for working in this YAML dialect, including support for type checking, completion lists, colorization and more.

Building on a Pulumi YAML Language Server Protocol (LSP) available for use in any IDE environment, the Pulumi YAML IDE support providers a wide range of editor integrations.

Type Checking

The Pulumi YAML LSP provides contextual warnings and errors directly within the editor.

Warnings: Alerts when a variable is defined but never referenced.
Errors:
- Invalid YAML document detection.
- Reference errors for non-existent variables.
- Duplicate names for variables/resources.

Hover Tooltips

Hover over a resource type token or function type token to see a popup with descriptions, helping you understand your resources and functions better.

Completion Lists

Experience semantic completion for:

Predefined Pulumi YAML keys such as “resources” or “properties”.
Resource properties or function arguments.
Type tokens for resources or functions.
Structured variables (e.g., referencing properties within complex objects).

Wrapping up

This extension is currently in public beta, and we’re eager to hear from the Pulumi community. Your feedback is crucial in helping us shape the future of the extension. If you have suggestions for new features or encounter any bugs, please open an issue.

What’s Next

We’re committed to making Pulumi development as efficient and enjoyable as possible. In the coming months, expect even more features and improvements, all aimed at helping you work smarter and faster. Stay tuned for updates as we continue to build out this powerful extension and bring new capabilities to the Pulumi platform.

New: Helm Chart v4 resource with new features and languages

Eron Wright — Thu, 13 Jun 2024 00:00:00 -0700

Today we’re happy to announce a new “v4” version of the Chart resource, available now in v4.13 of the Pulumi Kubernetes provider. The new kubernetes.helm.sh/v4.Chart resource is provided side-by-side with the existing kubernetes.helm.sh/v3.Chart resource. We expect to deprecate v3 in the future.

When you need to install a third-party application into your Kubernetes cluster, you’re likely to find a Helm chart for that in Artifact Hub or other registry. Pulumi provides two ways to apply a Helm chart, as outlined in Choosing the Right Helm Resource For Your Use Case. The Chart resource offers deeper integration with Pulumi and better drift remediation. v4 brings a host of new features, including enhanced SDK support across all Pulumi SDKs, full OCI registry support, improved handling of chart values, better connectivity for cluster interactions, and improved resource ordering. Let’s dig in.

What’s new

Let’s look at what’s new with Chart v4.

New language support - Java SDK & YAML SDK

The Chart v4 resource is a Pulumi Component that works consistently across all Pulumi SDKs. Earlier versions were implemented separately for each SDK, leading to various inconsistencies and limited SDK support.

Here, for example, is a simple deployment of cert-manager, a well-known Kubernetes add-on:

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

const certman = new kubernetes.helm.v4.Chart("cert-manager", {
 namespace: "cert-manager",
 chart: "oci://registry-1.docker.io/bitnamicharts/cert-manager",
 version: "1.3.1",
});

import pulumi
import pulumi_kubernetes as kubernetes

certman = kubernetes.helm.v4.Chart("cert-manager",
 namespace="cert-manager",
 chart="oci://registry-1.docker.io/bitnamicharts/cert-manager",
 version="1.3.1")

package main

import (
 helmv4 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/helm/v4"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 _, err := helmv4.NewChart(ctx, "cert-manager", &helmv4.ChartArgs{
 Namespace: pulumi.String("cert-manager"),
 Chart: pulumi.String("oci://registry-1.docker.io/bitnamicharts/cert-manager"),
 Version: pulumi.String("1.3.1"),
 })
 if err != nil {
 return err
 }
 return nil
 })
}

using System.Collections.Generic;
using System.Linq;
using Pulumi;
using Kubernetes = Pulumi.Kubernetes;

return await Deployment.RunAsync(() =>
{
 var certman = new Kubernetes.Helm.V4.Chart("cert-manager", new()
 {
 Namespace = "cert-manager",
 Chart = "oci://registry-1.docker.io/bitnamicharts/cert-manager",
 Version = "1.3.1",
 });

});

package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.kubernetes.helm.sh_v4.Chart;
import com.pulumi.kubernetes.helm.sh_v4.ChartArgs;
import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;

public class App {
 public static void main(String[] args) {
 Pulumi.run(App::stack);
 }

 public static void stack(Context ctx) {
 var certman = new Chart("cert-manager", ChartArgs.builder()
 .namespace("cert-manager")
 .chart("oci://registry-1.docker.io/bitnamicharts/cert-manager")
 .version("1.3.1")
 .build());

 }
}

resources:
 cert-manager:
 type: kubernetes:helm.sh/v4:Chart
 properties:
 namespace: cert-manager
 chart: oci://registry-1.docker.io/bitnamicharts/cert-manager
 version: "1.3.1"

OCI registry support

You can use container registries with OCI support such as Docker Hub to store and share Helm chart packages. The Chart v4 resource now has full support for OCI, bringing it to parity with the Release resource.

To use an authenticated OCI registry, you must first login using helm registry login or docker login.

Chart v4 also supports the use of Helm chart repositories, and adopts the same repositoryOpts API as was introduced in the Release resource.

Lock file support

Helm has support for lock files (Chart.lock) to control a chart’s dependencies. When deploying a chart from a local directory, Pulumi automatically rebuilds the chart’s dependencies if a lock file is present. See Helm Dependency Build for details.

Better handling of chart values

Chart v4 offers new ways to work with Chart values. It is now possible to use multiple values files and to use Pulumi Assets. Of course you can also use output values from other resources as chart values.

It is also possible to set a chart value to the contents of a text file, similarly to using Helm’s --set-file argument. To do that, simply use a Pulumi Asset as a value within the values map. This is useful for injecting large values into a chart, such as additional templates as supported by the extraDeploy parameter of some Bitnami charts.

Here’s an example of using a combination of values from different sources.

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

const certManager = new kubernetes.helm.v4.Chart("cert-manager", {
 namespace: "cert-manager",
 chart: "oci://registry-1.docker.io/bitnamicharts/cert-manager",
 version: "1.3.1",
 valueYamlFiles: [new pulumi.asset.FileAsset("values.yaml")],
 values: {
 commonLabels: {
 "pulumi.com/stackName": pulumi.getStack(),
 },
 extraDeploy: [new pulumi.asset.FileAsset("manifest.yaml")],
 },
});

import pulumi
import pulumi_kubernetes as kubernetes

cert_manager = kubernetes.helm.v4.Chart("cert-manager",
 namespace="cert-manager",
 chart="oci://registry-1.docker.io/bitnamicharts/cert-manager",
 version="1.3.1",
 value_yaml_files=[pulumi.FileAsset("values.yaml")],
 values={
 "commonLabels": {
 "pulumi.com/stackName": pulumi.get_stack(),
 },
 "extraDeploy": [pulumi.FileAsset("manifest.yaml")],
 })

package main

import (
 helmv4 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/helm/v4"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 _, err := helmv4.NewChart(ctx, "cert-manager", &helmv4.ChartArgs{
 Namespace: pulumi.String("cert-manager"),
 Chart: pulumi.String("oci://registry-1.docker.io/bitnamicharts/cert-manager"),
 Version: pulumi.String("1.3.1"),
 ValueYamlFiles: pulumi.AssetOrArchiveArray{
 pulumi.NewFileAsset("values.yaml"),
 },
 Values: pulumi.Map{
 "commonLabels": pulumi.Any(map[string]interface{}{
 "pulumi.com/stackName": ctx.Stack(),
 }),
 "extraDeploy": pulumi.Array{
 pulumi.NewFileAsset("manifest.yaml"),
 },
 },
 })
 if err != nil {
 return err
 }
 return nil
 })
}

using System.Collections.Generic;
using System.Linq;
using Pulumi;
using Kubernetes = Pulumi.Kubernetes;

return await Deployment.RunAsync(() =>
{
 var certManager = new Kubernetes.Helm.V4.Chart("cert-manager", new()
 {
 Namespace = "cert-manager",
 Chart = "oci://registry-1.docker.io/bitnamicharts/cert-manager",
 Version = "1.3.1",
 ValueYamlFiles = new[]
 {
 new FileAsset("values.yaml"),
 },
 Values =
 {
 { "commonLabels", new Dictionary<string, object?>
 {
 ["pulumi.com/stackName"] = Deployment.Instance.StackName,
 } },
 { "extraDeploy", new[]
 {
 new FileAsset("manifest.yaml"),
 } },
 },
 });

});

package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.deployment.Deployment;
import com.pulumi.kubernetes.helm.v4.Chart;
import com.pulumi.kubernetes.helm.v4.ChartArgs;
import com.pulumi.asset.FileAsset;
import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;

public class App {
 public static void main(String[] args) {
 Pulumi.run(App::stack);
 }

 public static void stack(Context ctx) {
 var certManager = new Chart("cert-manager", ChartArgs.builder()
 .namespace("cert-manager")
 .chart("oci://registry-1.docker.io/bitnamicharts/cert-manager")
 .version("1.3.1")
 .valueYamlFiles(new FileAsset("values.yaml"))
 .values(Map.ofEntries(
 Map.entry("commonLabels", Map.of("pulumi.com/stackName", Deployment.getInstance().getStackName())),
 Map.entry("extraDeploy", List.of(new FileAsset("manifest.yaml")))
 ))
 .build());

 }
}

resources:
 cert-manager:
 type: kubernetes:helm.sh/v4:Chart
 properties:
 namespace: cert-manager
 chart: oci://registry-1.docker.io/bitnamicharts/cert-manager
 version: "1.3.1"
 valueYamlFiles:
 - fn::fileAsset: values.yaml
 values:
 commonLabels:
 pulumi.com/stackName: ${pulumi.stack}
 extraDeploy:
 - fn::fileAsset: manifest.yaml

Better connectivity

You may now use charts that use chart functions requiring a connection to the cluster, e.g. to:

Check the Kubernetes server version with .Capabilities.KubeVersion
Check if an API version or kind is available with .Capabilities.APIVersions.Has
Use the lookup function in your templates to get existing objects in your live cluster.

Note that the lookup function is executed in both the preview and the non-preview mode, and keep in mind that the expected object may not exist during a preview.

Improved resource ordering

It’s now easy to wait for a chart’s resources to be installed before installing other resources, simply by using the dependsOn option. In earlier versions, we relied on a ready output property.

The Chart resource automatically detects dependencies between resources in the manifest(s). For example, it knows to install namespaces and Custom Resource Definitions (CRDs) first.

Use the config.kubernetes.io/depends-on annotation to declare an explicit resource dependency. The annotation accepts a list of resource references, delimited by commas.

It consists of the group, kind, name, and optionally the namespace, delimited by forward slashes.

Resource Scope	Format
namespace-scoped	`<group>/namespaces/<namespace>/<kind>/<name>`
cluster-scoped	`<group>/<kind>/<name>`

For resources in the “core” group, the empty string is used instead (for example: /namespaces/test/Pod/pod-a).

New-style Pulumi transformations

Pulumi has a new way to transform component resources and their children, the transforms options. The older transformations option doesn’t work with multi-language components like Chart v4. See Resource Option: transforms for more details.

Note: you cannot change an object’s namespace or name using a Pulumi transformation, and you cannot add or discard an object.

Here’s an example of using the transforms option to add the pulumi.com/patchForce annotation to a chart’s resources.

const applyPatchForceAnnotation = async (args: pulumi.ResourceTransformArgs) => {
 switch(args.type) {
 case "kubernetes:helm.sh/v4:Chart":
 break;
 default:
 args.props.metadata.annotations = {
 "pulumi.com/patchForce": "true",
 ...args.props.metadata.annotations
 }
 }
 return {
 props: args.props,
 opts: args.opts,
 };
};

const ingressController = new kubernetes.helm.v4.Chart("ingresscontroller", {
 chart: "nginx-ingress",
 namespace: ingressNs.metadata.name,
 repositoryOpts: {
 repo: "https://helm.nginx.com/stable",
 },
 version: "0.14.1",
}, {transforms: [applyPatchForceAnnotation]});

def apply_patchforce_annotation(args: ResourceTransformArgs):
 if not args.type_ == "kubernetes:helm.sh/v4:Chart":
 if not 'metadata' in args.props:
 args.props['metadata'] = {}
 if not 'annotations' in args.props['metadata']:
 args.props['metadata']['annotations'] = {}
 args.props['metadata']['annotations']['pulumi.com/patchForce'] = 'true'

 return ResourceTransformResult(
 props=args.props,
 opts=args.opts)

ingresscontroller = kubernetes.helm.v4.Chart(
 "ingresscontroller",
 chart="nginx-ingress",
 namespace=ingress_ns.metadata.name,
 repository_opts=kubernetes.helm.v3.RepositoryOptsArgs(
 repo="https://helm.nginx.com/stable",
 ),
 version="0.14.1",
 opts=pulumi.ResourceOptions(transforms=[apply_patchforce_annotation])
)

applyPatchForceAnnotation := func(ctx context.Context, rta *pulumi.ResourceTransformArgs) *pulumi.ResourceTransformResult {
 transform := func(applier interface{}) {
 o := rta.Props.ToMapOutputWithContext(ctx).ApplyT(applier)
 r, err := internals.UnsafeAwaitOutput(ctx, o)
 if err != nil {
 panic(err)
 }
 rta.Props = r.Value.(pulumi.Map)
 }

 switch rta.Type {
 case "kubernetes:helm.sh/v4:Chart":
 // Do nothing for Helm charts
 default:
 transform(func(obj map[string]any) pulumi.Map {
 // note: obj is an ordinary Unstructured object at this point.
 unstructured.SetNestedField(obj, "true", "metadata", "annotations", "pulumi.com/patchForce")
 return pulumi.ToMap(obj)
 })
 }
 return &pulumi.ResourceTransformResult{
 Props: rta.Props,
 Opts: rta.Opts,
 }
}

// Use Helm to install the Nginx ingress controller
_, err = helmv4.NewChart(ctx, "ingresscontroller", &helmv4.ChartArgs{
 Chart: pulumi.String("nginx-ingress"),
 Namespace: ingressNs.Metadata.Name(),
 RepositoryOpts: &helmv4.RepositoryOptsArgs{
 Repo: pulumi.String("https://helm.nginx.com/stable"),
 },
 Version: pulumi.String("0.14.1"),
}, pulumi.Transforms([]pulumi.ResourceTransform{applyPatchForceAnnotation}))
if err != nil {
 return err
}

Post-rendering support

New to v4 is support for a post-rendering command, with optional arguments, to be applied to the rendered manifest. See Advanced Helm Techniques: Post Rendering for details.

“Keep” policy

The Chart v4 resource now understands Helm resource policies, specifically “keep” which instructs Pulumi not to delete a given object when the resource is destroyed. Simply apply the helm.sh/resource-policy: keep annotation to the object. See Tell Helm Not To Uninstall a Resource for details.

Release name

Charts typically generate object names based on the Helm release name. By default, Chart v4 uses its own resource name as the release name. To customize the release name, set the name property on the Chart.

Some charts also accept a fullnameOverride value to control object naming, use that if possible.

Limitations

Not supported: Kubernetes transformations

Chart v4 does not support the transformations argument as seen in Chart v3, that facilitates a Kubernetes-centric transformation and/or discarding of objects from the rendered manifest.

One alternative is to use use Pulumi transformations to transform the object and resource options. Another is to use post-rendering, which we’ll cover next.

Not supported: Helm hooks

Some charts use hooks to perform pre- and post-installation tasks, and we recommend using the Release resource to install such charts. Another option is to emulate the hook by performing the task directly, using other Pulumi resources such as kubernetes.batch/v1.Job and kubernetes.core/v1.Secret.

Note that Chart v3 does not support hooks either but, for historical reasons, does emit the hooks as ordinary child resources.

Evolving: Resource outputs

The child resources created by the chart are presented to your program via the resources output, as an array of Pulumi Resource objects. In some SDKs, you can cast the resource into the appropriate resource type, e.g. corev1.ConfigMap. Not all SDKs support this (yet); see pulumi/pulumi#15788.

Deploy Helm charts with Pulumi

Apply any Helm chart with the Chart v4 resource and manage the cloud resources it depends on, like IAM roles and storage buckets, in the same program.

Get started

Example: Argo CD

Here’s a real-world example of installing Argo CD into a Kubernetes cluster, and of using Argo CD’s Application custom resource to deploy the ‘guestbook’ example.

import * as pulumi from "@pulumi/pulumi";
import * as kubernetes from "@pulumi/kubernetes";
import * as random from "@pulumi/random";

const ns = new kubernetes.core.v1.Namespace("ns", {metadata: {
 name: "argocd",
}});
const redisPasswordResource = new random.RandomPassword("redis-password", {length: 16});
const redisSecret = new kubernetes.core.v1.Secret("redis-secret", {
 metadata: {
 name: "argocd-redis",
 namespace: ns.metadata.apply(metadata => metadata.name),
 },
 type: "Opaque",
 stringData: {
 auth: redisPasswordResource.result,
 },
});
const argocd = new kubernetes.helm.v4.Chart("argocd", {
 chart: "argo-cd",
 version: "6.11.1",
 namespace: ns.metadata.apply(metadata => metadata.name),
 repositoryOpts: {
 repo: "https://argoproj.github.io/argo-helm",
 },
 values: {
 fullnameOverride: "",
 },
});
const guestbook = new kubernetes.yaml.v2.ConfigGroup("guestbook", {objs: [{
 apiVersion: "argoproj.io/v1alpha1",
 kind: "Application",
 metadata: {
 name: "guestbook",
 namespace: ns.metadata.apply(metadata => metadata.name),
 },
 spec: {
 project: "default",
 source: {
 repoURL: "https://github.com/argoproj/argocd-example-apps.git",
 targetRevision: "HEAD",
 path: "guestbook",
 },
 destination: {
 server: "https://kubernetes.default.svc",
 namespace: "default",
 },
 },
}]}, {
 dependsOn: [argocd],
});
export const redisPassword = redisPasswordResource.result;

import pulumi
import pulumi_kubernetes as kubernetes
import pulumi_random as random

ns = kubernetes.core.v1.Namespace("ns", metadata=kubernetes.meta.v1.ObjectMetaArgs(
 name="argocd",
))
redis_password_resource = random.RandomPassword("redis-password", length=16)
redis_secret = kubernetes.core.v1.Secret("redis-secret",
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 name="argocd-redis",
 namespace=ns.metadata.name,
 ),
 type="Opaque",
 string_data={
 "auth": redis_password_resource.result,
 })
argocd = kubernetes.helm.v4.Chart("argocd",
 chart="argo-cd",
 version="6.11.1",
 namespace=ns.metadata.name,
 repository_opts=kubernetes.helm.v4.RepositoryOptsArgs(
 repo="https://argoproj.github.io/argo-helm",
 ),
 values={
 "fullnameOverride": "",
 })
guestbook = kubernetes.yaml.v2.ConfigGroup("guestbook", objs=[{
 "apiVersion": "argoproj.io/v1alpha1",
 "kind": "Application",
 "metadata": {
 "name": "guestbook",
 "namespace": ns.metadata.name,
 },
 "spec": {
 "project": "default",
 "source": {
 "repoURL": "https://github.com/argoproj/argocd-example-apps.git",
 "targetRevision": "HEAD",
 "path": "guestbook",
 },
 "destination": {
 "server": "https://kubernetes.default.svc",
 "namespace": "default",
 },
 },
}],
opts=pulumi.ResourceOptions(depends_on=[argocd]))
pulumi.export("redisPassword", redis_password_resource.result)

package main

import (
 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/core/v1"
 helmv4 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/helm/v4"
 metav1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/meta/v1"
 yamlv2 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/yaml/v2"
 "github.com/pulumi/pulumi-random/sdk/v4/go/random"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 ns, err := corev1.NewNamespace(ctx, "ns", &corev1.NamespaceArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("argocd"),
 },
 })
 if err != nil {
 return err
 }
 redisPasswordResource, err := random.NewRandomPassword(ctx, "redis-password", &random.RandomPasswordArgs{
 Length: pulumi.Int(16),
 })
 if err != nil {
 return err
 }
 _, err = corev1.NewSecret(ctx, "redis-secret", &corev1.SecretArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("argocd-redis"),
 Namespace: ns.Metadata.ApplyT(func(metadata metav1.ObjectMeta) (*string, error) {
 return metadata.Name, nil
 }).(pulumi.StringPtrOutput),
 },
 Type: pulumi.String("Opaque"),
 StringData: pulumi.StringMap{
 "auth": redisPasswordResource.Result,
 },
 })
 if err != nil {
 return err
 }
 argocd, err := helmv4.NewChart(ctx, "argocd", &helmv4.ChartArgs{
 Chart: pulumi.String("argo-cd"),
 Version: pulumi.String("6.11.1"),
 Namespace: ns.Metadata.ApplyT(func(metadata metav1.ObjectMeta) (*string, error) {
 return metadata.Name, nil
 }).(pulumi.StringPtrOutput),
 RepositoryOpts: &helmv4.RepositoryOptsArgs{
 Repo: pulumi.String("https://argoproj.github.io/argo-helm"),
 },
 Values: pulumi.Map{
 "fullnameOverride": pulumi.Any(""),
 },
 })
 if err != nil {
 return err
 }
 _, err = yamlv2.NewConfigGroup(ctx, "guestbook", &yamlv2.ConfigGroupArgs{
 Objs: pulumi.Array{
 pulumi.Any(map[string]interface{}{
 "apiVersion": "argoproj.io/v1alpha1",
 "kind": "Application",
 "metadata": map[string]interface{}{
 "name": "guestbook",
 "namespace": ns.Metadata.ApplyT(func(metadata metav1.ObjectMeta) (*string, error) {
 return metadata.Name, nil
 }).(pulumi.StringPtrOutput),
 },
 "spec": map[string]interface{}{
 "project": "default",
 "source": map[string]interface{}{
 "repoURL": "https://github.com/argoproj/argocd-example-apps.git",
 "targetRevision": "HEAD",
 "path": "guestbook",
 },
 "destination": map[string]interface{}{
 "server": "https://kubernetes.default.svc",
 "namespace": "default",
 },
 },
 }),
 },
 }, pulumi.DependsOn([]pulumi.Resource{
 argocd,
 }))
 if err != nil {
 return err
 }
 ctx.Export("redisPassword", redisPasswordResource.Result)
 return nil
 })
}

using System.Collections.Generic;
using System.Linq;
using Pulumi;
using Kubernetes = Pulumi.Kubernetes;
using Random = Pulumi.Random;

return await Deployment.RunAsync(() =>
{
 var ns = new Kubernetes.Core.V1.Namespace("ns", new()
 {
 Metadata = new Kubernetes.Types.Inputs.Meta.V1.ObjectMetaArgs
 {
 Name = "argocd",
 },
 });

 var redisPasswordResource = new Random.RandomPassword("redis-password", new()
 {
 Length = 16,
 });

 var redisSecret = new Kubernetes.Core.V1.Secret("redis-secret", new()
 {
 Metadata = new Kubernetes.Types.Inputs.Meta.V1.ObjectMetaArgs
 {
 Name = "argocd-redis",
 Namespace = ns.Metadata.Apply(metadata => metadata.Name),
 },
 Type = "Opaque",
 StringData =
 {
 { "auth", redisPasswordResource.Result },
 },
 });

 var argocd = new Kubernetes.Helm.V4.Chart("argocd", new()
 {
 Chart = "argo-cd",
 Version = "6.11.1",
 Namespace = ns.Metadata.Apply(metadata => metadata.Name),
 RepositoryOpts = new Kubernetes.Types.Inputs.Helm.V4.RepositoryOptsArgs
 {
 Repo = "https://argoproj.github.io/argo-helm",
 },
 Values =
 {
 { "fullnameOverride", "" },
 },
 });

 var guestbook = new Kubernetes.Yaml.V2.ConfigGroup("guestbook", new()
 {
 Objs = new[]
 {
 new Dictionary<string, object?>
 {
 ["apiVersion"] = "argoproj.io/v1alpha1",
 ["kind"] = "Application",
 ["metadata"] = new Dictionary<string, object?>
 {
 ["name"] = "guestbook",
 ["namespace"] = ns.Metadata.Apply(metadata => metadata.Name),
 },
 ["spec"] = new Dictionary<string, object?>
 {
 ["project"] = "default",
 ["source"] = new Dictionary<string, object?>
 {
 ["repoURL"] = "https://github.com/argoproj/argocd-example-apps.git",
 ["targetRevision"] = "HEAD",
 ["path"] = "guestbook",
 },
 ["destination"] = new Dictionary<string, object?>
 {
 ["server"] = "https://kubernetes.default.svc",
 ["namespace"] = "default",
 },
 },
 },
 },
 }, new ComponentResourceOptions
 {
 DependsOn =
 {
 argocd,
 },
 });

 return new Dictionary<string, object?>
 {
 ["redisPassword"] = redisPasswordResource.Result,
 };
});

package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.kubernetes.core.v1.Namespace;
import com.pulumi.kubernetes.core.v1.NamespaceArgs;
import com.pulumi.kubernetes.meta.v1.inputs.ObjectMetaArgs;
import com.pulumi.random.RandomPassword;
import com.pulumi.random.RandomPasswordArgs;
import com.pulumi.kubernetes.core.v1.Secret;
import com.pulumi.kubernetes.core.v1.SecretArgs;
import com.pulumi.kubernetes.helm.v4.Chart;
import com.pulumi.kubernetes.helm.v4.ChartArgs;
import com.pulumi.kubernetes.helm.v4.inputs.RepositoryOptsArgs;
import com.pulumi.kubernetes.yaml.v2.ConfigGroup;
import com.pulumi.kubernetes.yaml.v2.ConfigGroupArgs;
import com.pulumi.resources.ComponentResourceOptions;
import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;

public class App {
 public static void main(String[] args) {
 Pulumi.run(App::stack);
 }

 public static void stack(Context ctx) {
 var ns = new Namespace("ns", NamespaceArgs.builder()
 .metadata(ObjectMetaArgs.builder()
 .name("argocd")
 .build())
 .build());

 var redisPasswordResource = new RandomPassword("redisPasswordResource", RandomPasswordArgs.builder()
 .length(16)
 .build());

 var redisSecret = new Secret("redisSecret", SecretArgs.builder()
 .metadata(ObjectMetaArgs.builder()
 .name("argocd-redis")
 .namespace(ns.metadata().applyValue(metadata -> metadata.name().get()))
 .build())
 .type("Opaque")
 .stringData(redisPasswordResource.result().applyValue(password -> Map.of("auth", password)))
 .build());

 var argocd = new Chart("argocd", ChartArgs.builder()
 .chart("argo-cd")
 .version("6.11.1")
 .namespace(ns.metadata().applyValue(metadata -> metadata.name().get()))
 .repositoryOpts(RepositoryOptsArgs.builder()
 .repo("https://argoproj.github.io/argo-helm")
 .build())
 .values(Map.of("fullnameOverride", ""))
 .build());

 var guestbook = new ConfigGroup("guestbook", ConfigGroupArgs.builder()
 .objs(Map.ofEntries(
 Map.entry("apiVersion", "argoproj.io/v1alpha1"),
 Map.entry("kind", "Application"),
 Map.entry("metadata", Map.ofEntries(
 Map.entry("name", "guestbook"),
 Map.entry("namespace", ns.metadata().applyValue(metadata -> metadata.name().get()))
 )),
 Map.entry("spec", Map.ofEntries(
 Map.entry("project", "default"),
 Map.entry("source", Map.ofEntries(
 Map.entry("repoURL", "https://github.com/argoproj/argocd-example-apps.git"),
 Map.entry("targetRevision", "HEAD"),
 Map.entry("path", "guestbook")
 )),
 Map.entry("destination", Map.ofEntries(
 Map.entry("server", "https://kubernetes.default.svc"),
 Map.entry("namespace", "default")
 ))
 ))
 ))
 .build(), ComponentResourceOptions.builder()
 .dependsOn(argocd)
 .build());

 ctx.export("redisPassword", redisPasswordResource.result());
 }
}

resources:
 ns:
 type: kubernetes:core/v1:Namespace
 properties:
 metadata:
 name: argocd

 redis-password:
 type: random:RandomPassword
 properties:
 length: 16

 redis-secret:
 type: kubernetes:core/v1:Secret
 properties:
 metadata:
 name: argocd-redis
 namespace: ${ns.metadata.name}
 type: Opaque
 stringData:
 auth: ${redis-password.result}
 options:
 retainOnDelete: true

 argocd:
 type: kubernetes:helm.sh/v4:Chart
 properties:
 chart: argo-cd
 version: "6.11.1"
 namespace: ${ns.metadata.name}
 repositoryOpts:
 repo: https://argoproj.github.io/argo-helm
 values:
 fullnameOverride: ""

 guestbook:
 type: kubernetes:yaml/v2:ConfigGroup
 properties:
 objs:
 - apiVersion: argoproj.io/v1alpha1
 kind: Application
 metadata:
 name: guestbook
 namespace: ${ns.metadata.name}
 spec:
 project: default
 source:
 repoURL: https://github.com/argoproj/argocd-example-apps.git
 targetRevision: HEAD
 path: guestbook
 destination:
 server: https://kubernetes.default.svc
 namespace: default
 options:
 dependsOn:
 - ${argocd}

outputs:
 redisPassword: ${redis-password.result}

The program creates the argocd namespace, installs the ArgoCD server, and then creates an ArgoCD Application resource. Observe how the program installs and uses a Custom Resource Definition (CRD) successfully, and uses dependsOn to ensure that the CRD is installed before using it.

The argo-cd chart normally makes use of a Helm hook to initialize a password for the redis server. Since the Chart v4 resource doesn’t support Helm hooks, this program creates the password directly.

Conclusion

Pulumi loves empowering developers to use the best tools for the job, and we recommend using Helm charts to install third-party Kubernetes applications. Pulumi complements Helm by handling the cloud resources that are often required, such as an IAM Role or cloud storage bucket. Such combinations make for great reusable componentry.

Check out the following links to learn more about Pulumi Kubernetes today!

New: ConfigGroup, ConfigFile resources for Java, YAML SDKs

Eron Wright — Fri, 12 Apr 2024 00:00:00 -0700

The Pulumi Kubernetes provider makes it easy to deploy Kubernetes resources to your cluster, giving you options based on how your application or workload is packaged. The options include strongly-typed resources for standard Kubernetes types, Helm charts, Kustomizations, and Kubernetes manifests.

In v4.10, we leveled up the support for working with Kubernetes manifests with the introduction of the yaml/v2 package. The package provides new implementations of the ConfigGroup and ConfigFile resources, expanding support to the Pulumi Java SDK and to Pulumi YAML. The new implementations are also smarter about applying the objects in the correct order.

Please note that these resources are in a preview stage of maturity, as we continue to round out the feature set. These new resources are provided side-by-side with the existing implementations.

Let’s explore how it’s easier than ever to deploy diverse Kubernetes workloads using Pulumi.

kubernetes.yaml/v2.ConfigGroup

The ConfigGroup resource creates a set of Kubernetes objects from Kubernetes manifests and/or object literals. The Kubernetes manifest may be supplied using any combination of the following methods:

a filename or a list of filenames.
a file pattern or a list of file patterns.
a literal string containing YAML or JSON text.
a literal object or a list of objects.

The ConfigGroup resource accepts the following input properties:

Property	Description
`files`	Set of files, patterns and/or URLs to Kubernetes manifest files. Filenames containing any of the characters ``, `?`, and `[` are treated as patterns*.
`objs`	Set of Kubernetes objects.
`yaml`	A Kubernetes manifest as a YAML or JSON string.
`resourcePrefix`	A prefix for auto-generated names of the child resources. Defaults to the `ConfigGroup` name.
`skipAwait`	Skips over the readiness checks on the child resources.

Note that all objects defined within the manifest must have a metadata.name field; Pulumi autonaming is not supported.

See the API Reference documentation for more information.

Manifest Files

Here’s an example of applying a Kubernetes manifest file to your cluster.

name: demo-cg-1
runtime: yaml
resources:
 cg:
 type: kubernetes:yaml/v2:ConfigGroup
 properties:
 files:
 - ./manifest.yaml

YAML Text

Here’s how to apply an inline manifest.

name: demo-cg-2
runtime: yaml
resources:
 cg:
 type: kubernetes:yaml/v2:ConfigGroup
 properties:
 yaml: |
 apiVersion: v1
 kind: ConfigMap
 metadata:
 name: my-server-config
 data:
 altGreeting: "Good Morning!"
 ---
 apiVersion: v1
 kind: Secret
 metadata:
 name: my-dotfile-secret
 data:
 .secret-file: dmFsdWUtMg0KDQo=

Object Literals

With ConfigGroup it’s easy to define a Kubernetes object using Pulumi property values. Let’s create a Kubernetes namespace and deploy a custom resource into that namespace.

name: demo-cg-3
runtime: yaml
resources:
 ns:
 type: kubernetes:core/v1:Namespace
 cg:
 type: kubernetes:yaml/v2:ConfigGroup
 properties:
 objs:
 - apiVersion: stable.example.com/v1
 kind: CronTab
 metadata:
 namespace: ${ns.metadata.name}
 name: my-crontab
 spec:
 cronSpec: "* * * * */5"

This feature is especially useful for Pulumi YAML, since the apiextensions.k8s.io:CustomResource resource isn’t supported yet (see pulumi-kubernetes#2787).

Resource Ordering

The ConfigGroup resource automatically detects dependencies between resources in the manifest(s). For example, it knows to install namespaces and Custom Resource Definitions (CRDs) first.

Use the config.kubernetes.io/depends-on annotation to declare an explicit resource dependency. The annotation accepts a list of resource references, delimited by commas.

It consists of the group, kind, name, and optionally the namespace, delimited by forward slashes.

Resource Scope	Format
namespace-scoped	`<group>/namespaces/<namespace>/<kind>/<name>`
cluster-scoped	`<group>/<kind>/<name>`

For resources in the “core” group, the empty string is used instead (for example: /namespaces/test/Pod/pod-a).

Resource Prefixes

The purpose of the resource prefix is to ensure the uniqueness of child resource names, as described in Pulumi: Resource Names. The best practice is to use the component name as a prefix, and now that’s the default behavior.

Note that the resource prefix is not applied to the Kubernetes object names.

Transformation Support

The Kubernetes provider generally supports resource transformations, e.g. to apply a resource alias or to apply an object name prefix or object label. Transformations aren’t yet possible with the new ConfigGroup resource (see pulumi/pulumi#12996), but stay tuned as we work towards a GA release later this year.

kubernetes.yaml/v2.ConfigFile

The ConfigFile resource creates a set of Kubernetes objects from a Kubernetes manifest. While ConfigGroup offers a superset of functionality, the ConfigFile gives a concise way to apply a specific manifest.

The ConfigFile resource accepts the following input properties:

Property	Description
`file`	A file or URL to a Kubernetes manifest file.
`resourcePrefix`	A prefix for auto-generated names of the child resources. Defaults to the `ConfigFile` name.
`skipAwait`	Skips over the readiness checks on the child resources.

See the API Reference documentation for more information.

Manifest File

Here’s an example of applying a Kubernetes manifest file to your cluster:

name: demo-cg-1
runtime: yaml
resources:
 cf:
 type: kubernetes:yaml/v2:ConfigFile
 properties:
 file: ./manifest.yaml

Example: Certificate Manager

Here’s a complete example of how to install and use cert-manager using ConfigGroup resources.

name: cert-manager
runtime: yaml
description: Installs cert-manager. See https://cert-manager.io/docs/installation/kubectl/ for details.
variables: {}
resources:
 install:
 type: kubernetes:yaml/v2:ConfigGroup
 properties:
 files:
 - https://github.com/cert-manager/cert-manager/releases/download/v1.14.4/cert-manager.yaml
 test:
 type: kubernetes:yaml/v2:ConfigGroup
 options:
 dependsOn:
 - ${install}
 properties:
 yaml: |
 apiVersion: v1
 kind: Namespace
 metadata:
 name: cert-manager-test
 ---
 apiVersion: cert-manager.io/v1
 kind: Issuer
 metadata:
 name: test-selfsigned
 namespace: cert-manager-test
 spec:
 selfSigned: {}
 ---
 apiVersion: cert-manager.io/v1
 kind: Certificate
 metadata:
 name: selfsigned-cert
 namespace: cert-manager-test
 annotations:
 config.kubernetes.io/depends-on: cert-manager.io/namespaces/cert-manager-test/Issuer/test-selfsigned
 spec:
 dnsNames:
 - example.com
 secretName: selfsigned-cert-tls
 issuerRef:
 name: test-selfsigned

Conclusion

With the new resources in yaml/v2, we’re excited to enable new scenarios in Pulumi YAML and the Pulumi Java SDK. Stay tuned for new editions of the Chart and Directory resources, coming soon.

This is part of a broad initiative to use Multi-Language Component (MLC) technology to offer a consistent experience across the Pulumi SDKs. See pulumi-kubernetes#1971 for details.

Check out the following links to learn more about Pulumi Kubernetes today!

Secure your Kubernetes toolchain with Pulumi ESC and OIDC

Levi Blackstone — Tue, 21 Nov 2023 00:00:00 -0700

Keeping long-lived kubeconfig around on disk is insecure and error-prone. You need a secure workflow that removes tedium. With Pulumi and ESC, we provide an automated workflow that generates a kubeconfig on-the-fly for every command using short-term credentials issued via OIDC. This makes it easy for your team to connect to a given Kubernetes environment, and it works well with Kubernetes tools such as kubectl and the Pulumi Kubernetes provider. Let’s take a look.

In this post, we will create a Kubernetes cluster, deploy an application to the created cluster, and then use kubectl to check on the deployed application. Pulumi gives you great flexibility to factor your infrastructure into reusable parts, and we’ll do that here. With ESC, we’ll define an environment that provides access to an AWS account, and use that environment to create the cluster. Then we’ll define an environment that encapsulates the kubeconfig needed to connect to that cluster.

Create a Kubernetes Cluster

First, we create a Kubernetes cluster using the pulumi-eks component.

import * as pulumi from "@pulumi/pulumi";
import * as eks from "@pulumi/eks";

const eksCluster = new eks.Cluster("eks-cluster", {});
export const kubeconfig = eksCluster.kubeconfig;

import pulumi
import pulumi_eks as eks

eks_cluster = eks.Cluster("eks-cluster")
pulumi.export("kubeconfig", eks_cluster.kubeconfig)

import (
 "github.com/pulumi/pulumi-eks/sdk/go/eks"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 eksCluster, err := eks.NewCluster(ctx, "eks-cluster", nil)
 if err != nil {
 return err
 }
 ctx.Export("kubeconfig", eksCluster.Kubeconfig)
 return nil
 })
}

using System.Collections.Generic;
using System.Linq;
using Pulumi;
using Eks = Pulumi.Eks;

return await Deployment.RunAsync(() =>
{
 var eksCluster = new Eks.Cluster("eks-cluster");

 return new Dictionary<string, object?>
 {
 ["kubeconfig"] = eksCluster.Kubeconfig,
 };
});

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.eks.Cluster;

public class App {
 public static void main(String[] args) {
 Pulumi.run(App::stack);
 }

 public static void stack(Context ctx) {
 var eksCluster = new Cluster("eksCluster");

 ctx.export("kubeconfig", eksCluster.kubeconfig());
 }
}

name: eks-cluster
runtime: nodejs
description: EKS Kubernetes Cluster
resources:
 eks-cluster:
 type: eks:Cluster
outputs:
 kubeconfig: ${eks-cluster.kubeconfig}

This component includes an output value for the cluster’s kubeconfig that we can use to connect to the cluster. However, before we create the cluster, we need to configure AWS credentials so that Pulumi can deploy the requested changes. While it is possible to set this configuration directly on the stack, let’s see how it can be done with Pulumi ESC. First, we create the following ESC environment (the aws-sandbox environment):

values:
 aws:
 creds:
 fn::open::aws-login:
 oidc:
 duration: 1h
 roleArn: arn:aws:iam::0123456789:role/deploy-oidc
 sessionName: pulumi-environments-session
 environmentVariables:
 AWS_ACCESS_KEY_ID: ${aws.creds.keyId}
 AWS_SECRET_ACCESS_KEY: ${aws.creds.secretAccessKey}
 AWS_SESSION_TOKEN: ${aws.creds.sessionToken}
 pulumiConfig:
 aws:region: us-west-2

Notice that this environment uses the aws-login ESC provider to dynamically load short-lived credentials using OIDC. These credentials are then exposed as environment variables for consumers of this environment. We also set the AWS region in the pulumiConfig section to configure the region for pulumi to manage resources with the pulumi-aws provider.

To have Pulumi use this ESC environment when deploying the cluster, we set the following configuration for our stack:

environment:
 - aws-sandbox

The environment key accepts a list of ESC environments to import. When the stack is updated, pulumi automatically sets the configured environment variables and stack configuration based on the ESC environment. We run our update, and Pulumi creates our EKS cluster.

pulumi up --skip-preview
Updating (demo)
Type Name Status
+ pulumi:pulumi:Stack eks-cluster-demo created (577s)
+ └─ eks:index:Cluster eks-cluster created (561s)
+ ├─ eks:index:ServiceRole eks-cluster-eksRole created (2s)
+ │ ├─ aws:iam:Role eks-cluster-eksRole-role created (0.78s)
+ │ └─ aws:iam:RolePolicyAttachment eks-cluster-eksRole-4b490823 created (0.44s)
+ ├─ eks:index:ServiceRole eks-cluster-instanceRole created (3s)
+ │ ├─ aws:iam:Role eks-cluster-instanceRole-role created (0.85s)
+ │ ├─ aws:iam:RolePolicyAttachment eks-cluster-instanceRole-3eb088f2 created (0.46s)
+ │ ├─ aws:iam:RolePolicyAttachment eks-cluster-instanceRole-03516f97 created (0.59s)
+ │ └─ aws:iam:RolePolicyAttachment eks-cluster-instanceRole-e1b295bd created (0.75s)
+ ├─ eks:index:RandomSuffix eks-cluster-cfnStackName created (0.49s)
+ ├─ aws:ec2:SecurityGroup eks-cluster-eksClusterSecurityGroup created (1s)
+ ├─ aws:iam:InstanceProfile eks-cluster-instanceProfile created (0.48s)
+ ├─ aws:eks:Cluster eks-cluster-eksCluster created (441s)
+ ├─ aws:ec2:SecurityGroupRule eks-cluster-eksClusterInternetEgressRule created (0.81s)
+ ├─ aws:ec2:SecurityGroup eks-cluster-nodeSecurityGroup created (1s)
+ ├─ pulumi:providers:kubernetes eks-cluster-eks-k8s created (0.14s)
+ ├─ eks:index:VpcCni eks-cluster-vpc-cni created (2s)
+ ├─ kubernetes:core/v1:ConfigMap eks-cluster-nodeAccess created (0.60s)
+ ├─ aws:ec2:SecurityGroupRule eks-cluster-eksExtApiServerClusterIngressRule created (1s)
+ ├─ aws:ec2:SecurityGroupRule eks-cluster-eksClusterIngressRule created (1s)
+ ├─ aws:ec2:SecurityGroupRule eks-cluster-eksNodeInternetEgressRule created (1s)
+ ├─ aws:ec2:SecurityGroupRule eks-cluster-eksNodeClusterIngressRule created (2s)
+ ├─ aws:ec2:SecurityGroupRule eks-cluster-eksNodeIngressRule created (2s)
+ ├─ aws:ec2:LaunchConfiguration eks-cluster-nodeLaunchConfiguration created (1s)
+ ├─ aws:cloudformation:Stack eks-cluster-nodes created (108s)
+ └─ pulumi:providers:kubernetes eks-cluster-provider created (0.12s)
Outputs:
kubeconfig: {
apiVersion : "v1"
clusters : [
[0]: {
cluster: {
certificate-authority-data: "<redacted>"
server : "https://FB9978041F7B72B227B7E95F076822E4.gr7.us-west-2.eks.amazonaws.com"
}
name : "kubernetes"
}
]
contexts : [
[0]: {
context: {
cluster: "kubernetes"
user : "aws"
}
name : "aws"
}
]
current-context: "aws"
kind : "Config"
users : [
[0]: {
name: "aws"
user: {
exec: {
apiVersion: "client.authentication.k8s.io/v1beta1"
args : [
[0]: "eks"
[1]: "get-token"
[2]: "--cluster-name"
[3]: "eks-cluster-eksCluster-1268ff9"
]
command : "aws"
env : [
[0]: {
name : "KUBERNETES_EXEC_INFO"
value: (json) {
apiVersion: "client.authentication.k8s.io/v1beta1"
}
}
]
}
}
}
]
}
Resources:
+ 27 created
Duration: 9m38s

Connect to the cluster

Let’s create another Pulumi ESC environment called eks-sandbox to encapsulate the configuration needed to connect to the EKS cluster.

imports:
 - aws-sandbox
values:
 stacks:
 fn::open::pulumi-stacks:
 stacks:
 eks-cluster:
 stack: eks-cluster/demo
 kubeconfig: {'fn::toJSON': "${stacks.eks-cluster.kubeconfig}"}
 pulumiConfig:
 kubernetes:kubeconfig: ${kubeconfig}
 files:
 KUBECONFIG: ${kubeconfig}

This ESC environment uses another ESC provider to reference outputs from Pulumi stacks in your organization. In this case, we specify that we want to read outputs from the eks-cluster/demo stack, and then export the kubeconfig output from that stack as pulumiConfig and files. As we saw on the cluster environment, pulumiConfig sets configuration for Pulumi providers, so this allows us to run our stack and deploy the application to our cluster.

We import the aws-sandbox environment defined earlier, to provide the user with AWS credentials to authenticate to the EKS cluster.

Since the eks-sandbox environment defines a KUBECONFIG variable that kubectl understands, we can run kubectl in the context of this environment like this:

$ pulumi env run eks-sandbox -- kubectl cluster-info
Kubernetes control plane is running at https://2F3303BF9E03F8D61099AAB5ED6F31A4.gr7.us-west-2.eks.amazonaws.com
CoreDNS is running at https://2F3303BF9E03F8D61099AAB5ED6F31A4.gr7.us-west-2.eks.amazonaws.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Deploy an application to the cluster

Now, we want to deploy an application to our new EKS cluster. While we could have included this in the same stack as the cluster, it is generally better to follow the separation of concerns principle, and manage applications separately from the underlying infrastructure. To achieve this goal, we create a new application stack with the following program:

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

const nginxDeployment = new kubernetes.apps.v1.Deployment("nginx-deployment", {
 metadata: {
 name: "nginx",
 labels: {
 app: "nginx",
 },
 },
 spec: {
 replicas: 3,
 selector: {
 matchLabels: {
 app: "nginx",
 },
 },
 template: {
 metadata: {
 labels: {
 app: "nginx",
 },
 },
 spec: {
 containers: [{
 name: "nginx",
 image: "nginx",
 ports: [{
 containerPort: 80,
 }],
 }],
 },
 },
 },
});
const nginxService = new kubernetes.core.v1.Service("nginx-service", {
 metadata: {
 name: "nginx",
 },
 spec: {
 type: "LoadBalancer",
 selector: {
 app: "nginx",
 },
 ports: [{
 protocol: "TCP",
 port: 80,
 }],
 },
});

import pulumi
import pulumi_kubernetes as kubernetes

nginx_deployment = kubernetes.apps.v1.Deployment("nginx-deployment",
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 name="nginx",
 labels={
 "app": "nginx",
 },
 ),
 spec=kubernetes.apps.v1.DeploymentSpecArgs(
 replicas=3,
 selector=kubernetes.meta.v1.LabelSelectorArgs(
 match_labels={
 "app": "nginx",
 },
 ),
 template=kubernetes.core.v1.PodTemplateSpecArgs(
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 labels={
 "app": "nginx",
 },
 ),
 spec=kubernetes.core.v1.PodSpecArgs(
 containers=[kubernetes.core.v1.ContainerArgs(
 name="nginx",
 image="nginx",
 ports=[kubernetes.core.v1.ContainerPortArgs(
 container_port=80,
 )],
 )],
 ),
 ),
 ))
nginx_service = kubernetes.core.v1.Service("nginx-service",
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 name="nginx",
 ),
 spec=kubernetes.core.v1.ServiceSpecArgs(
 type="LoadBalancer",
 selector={
 "app": "nginx",
 },
 ports=[kubernetes.core.v1.ServicePortArgs(
 protocol="TCP",
 port=80,
 )],
 ))

import (
 appsv1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/apps/v1"
 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/core/v1"
 metav1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/meta/v1"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 _, err := appsv1.NewDeployment(ctx, "nginx-deployment", &appsv1.DeploymentArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("nginx"),
 Labels: pulumi.StringMap{
 "app": pulumi.String("nginx"),
 },
 },
 Spec: &appsv1.DeploymentSpecArgs{
 Replicas: pulumi.Int(3),
 Selector: &metav1.LabelSelectorArgs{
 MatchLabels: pulumi.StringMap{
 "app": pulumi.String("nginx"),
 },
 },
 Template: &corev1.PodTemplateSpecArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Labels: pulumi.StringMap{
 "app": pulumi.String("nginx"),
 },
 },
 Spec: &corev1.PodSpecArgs{
 Containers: corev1.ContainerArray{
 &corev1.ContainerArgs{
 Name: pulumi.String("nginx"),
 Image: pulumi.String("nginx"),
 Ports: corev1.ContainerPortArray{
 &corev1.ContainerPortArgs{
 ContainerPort: pulumi.Int(80),
 },
 },
 },
 },
 },
 },
 },
 })
 if err != nil {
 return err
 }
 _, err = corev1.NewService(ctx, "nginx-service", &corev1.ServiceArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("nginx"),
 },
 Spec: &corev1.ServiceSpecArgs{
 Type: pulumi.String("LoadBalancer"),
 Selector: pulumi.StringMap{
 "app": pulumi.String("nginx"),
 },
 Ports: corev1.ServicePortArray{
 &corev1.ServicePortArgs{
 Protocol: pulumi.String("TCP"),
 Port: pulumi.Int(80),
 },
 },
 },
 })
 if err != nil {
 return err
 }
 return nil
 })
}

using System.Collections.Generic;
using System.Linq;
using Pulumi;
using Kubernetes = Pulumi.Kubernetes;

return await Deployment.RunAsync(() =>
{
 var nginxDeployment = new Kubernetes.Apps.V1.Deployment("nginx-deployment", new()
 {
 Metadata = new Kubernetes.Types.Inputs.Meta.V1.ObjectMetaArgs
 {
 Name = "nginx",
 Labels =
 {
 { "app", "nginx" },
 },
 },
 Spec = new Kubernetes.Types.Inputs.Apps.V1.DeploymentSpecArgs
 {
 Replicas = 3,
 Selector = new Kubernetes.Types.Inputs.Meta.V1.LabelSelectorArgs
 {
 MatchLabels =
 {
 { "app", "nginx" },
 },
 },
 Template = new Kubernetes.Types.Inputs.Core.V1.PodTemplateSpecArgs
 {
 Metadata = new Kubernetes.Types.Inputs.Meta.V1.ObjectMetaArgs
 {
 Labels =
 {
 { "app", "nginx" },
 },
 },
 Spec = new Kubernetes.Types.Inputs.Core.V1.PodSpecArgs
 {
 Containers = new[]
 {
 new Kubernetes.Types.Inputs.Core.V1.ContainerArgs
 {
 Name = "nginx",
 Image = "nginx",
 Ports = new[]
 {
 new Kubernetes.Types.Inputs.Core.V1.ContainerPortArgs
 {
 ContainerPortValue = 80,
 },
 },
 },
 },
 },
 },
 },
 });

 var nginxService = new Kubernetes.Core.V1.Service("nginx-service", new()
 {
 Metadata = new Kubernetes.Types.Inputs.Meta.V1.ObjectMetaArgs
 {
 Name = "nginx",
 },
 Spec = new Kubernetes.Types.Inputs.Core.V1.ServiceSpecArgs
 {
 Type = "LoadBalancer",
 Selector =
 {
 { "app", "nginx" },
 },
 Ports = new[]
 {
 new Kubernetes.Types.Inputs.Core.V1.ServicePortArgs
 {
 Protocol = "TCP",
 Port = 80,
 },
 },
 },
 });

});

import java.security.Provider.Service;
import java.util.Map;

import javax.naming.Context;

import com.pulumi.Pulumi;
import com.pulumi.kubernetes.apps_v1.Deployment;
import com.pulumi.kubernetes.apps_v1.DeploymentArgs;
import com.pulumi.kubernetes.apps_v1.inputs.DeploymentSpecArgs;
import com.pulumi.kubernetes.core_v1.ServiceArgs;
import com.pulumi.kubernetes.core_v1.inputs.PodSpecArgs;
import com.pulumi.kubernetes.core_v1.inputs.PodTemplateSpecArgs;
import com.pulumi.kubernetes.core_v1.inputs.ServiceSpecArgs;
import com.pulumi.kubernetes.meta_v1.inputs.LabelSelectorArgs;
import com.pulumi.kubernetes.meta_v1.inputs.ObjectMetaArgs;

public class App {
 public static void main(String[] args) {
 Pulumi.run(App::stack);
 }

 public static void stack(Context ctx) {
 var nginxDeployment = new Deployment("nginxDeployment", DeploymentArgs.builder()
 .metadata(ObjectMetaArgs.builder()
 .name("nginx")
 .labels(Map.of("app", "nginx"))
 .build())
 .spec(DeploymentSpecArgs.builder()
 .replicas(3)
 .selector(LabelSelectorArgs.builder()
 .matchLabels(Map.of("app", "nginx"))
 .build())
 .template(PodTemplateSpecArgs.builder()
 .metadata(ObjectMetaArgs.builder()
 .labels(Map.of("app", "nginx"))
 .build())
 .spec(PodSpecArgs.builder()
 .containers(ContainerArgs.builder()
 .name("nginx")
 .image("nginx")
 .ports(ContainerPortArgs.builder()
 .containerPort(80)
 .build())
 .build())
 .build())
 .build())
 .build())
 .build());

 var nginxService = new Service("nginxService", ServiceArgs.builder()
 .metadata(ObjectMetaArgs.builder()
 .name("nginx")
 .build())
 .spec(ServiceSpecArgs.builder()
 .type("LoadBalancer")
 .selector(Map.of("app", "nginx"))
 .ports(ServicePortArgs.builder()
 .protocol("TCP")
 .port(80)
 .build())
 .build())
 .build());

 }
}

name: yaml-example
runtime: yaml
description: Deployment + Service
resources:
 nginx-deployment:
 type: kubernetes:apps/v1:Deployment
 properties:
 metadata:
 name: nginx
 labels:
 app: nginx
 spec:
 replicas: 3
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx
 image: "nginx"
 ports:
 - containerPort: 80
 nginx-service:
 type: kubernetes:core/v1:Service
 properties:
 metadata:
 name: nginx
 spec:
 type: LoadBalancer
 selector:
 app: nginx
 ports:
 - protocol: TCP
 port: 80

We need to set some configuration before we deploy this stack. In this case, we need a kubeconfig to allow the pulumi-kubernetes provider to connect to our EKS cluster.

We import the eks-sandbox environment with the following stack configuration:

environment:
 - eks-sandbox

Now we update our stack, and see that our application gets deployed to the cluster, without needing to manually configure any credentials – ESC automatically injects them for us!

pulumi up --skip-preview
Updating (demo)
Type Name Status
+ pulumi:pulumi:Stack yaml-example-demo created (0.31s)
+ ├─ kubernetes:core/v1:Service nginx-service created (10s)
+ └─ kubernetes:apps/v1:Deployment nginx-deployment created (2s)
Resources:
+ 3 created
Duration: 13s

Now that the application is deployed, let’s take a look using kubectl:

$ pulumi env run eks-sandbox -- kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 3/3 3 3 103s

ESC environments can be used with the pulumi CLI using the pulumi env command.

Export Files

As we see in the ESC environment definition named eks-sandbox, there’s a files section (under values) for defining values that are automatically exported as temporary files when you run the environment. You can use this feature to generate configuration files to support your preferred tools. Pulumi exports each key-value pair as a temporary file containing the actual value, and an associated environment variable pointing to it.

Earlier we exported an environment variable named KUBECONFIG with a dynamic value based on a stack output. Here’s a similar example with the configuration declared statically:

values:
 files:
 KUBECONFIG: |
 apiVersion: v1
 kind: Config
 clusters:
 - cluster:
 server: https://127.0.0.1:6443
 name: docker-desktop

Conclusion

Pulumi ESC makes it easier than ever to tame infrastructure complexity. For this demo, we created two reusable ESC environments to configure AWS and Kubernetes credentials, created an EKS cluster, deployed a load-balanced application to the cluster, and configured our local toolchain to connect to the cluster. Since we factored the shared configuration into ESC environments, it is easy to extend this example to deploy additional AWS or Kubernetes resources. Pulumi ESC supports dynamic credentials using OIDC across AWS, Azure, and Google Cloud, with additional providers on the roadmap. Check out the following links to learn more about Pulumi ESC today!

Pulumi Blog: Eron Wright

Pulumi Kubernetes Operator v2.3.0: Preview Mode and Structured Configuration

Preview mode: Validate infrastructure changes before deployment

Structured configuration: Native support for complex data types

Bug fixes and reliability improvements

Upgrading to v2.3.0

Get started today

Azure Native 3.8: Unified Credentials and Private Clouds

Simplified Authentication Across Environments

What’s New

Real-World Benefits

Getting Started

Private Azure Cloud Support

How To Use

Disabling Instance Discovery

How To Use

Authentication in AKS with Workload Identity

Walkthrough

Create an AKS Cluster

Install the Pulumi Kubernetes Operator

Configure a Pulumi Cloud Access Token

Update the Kubernetes Service Account

Define an Example Program

Run the Program using Workload Identity

Conclusion

The Pulumi Go Provider SDK is Now Generally Available

Unlock the Full Potential of Your Cloud Ecosystem

Key Enhancements for Your Team

Defining and Testing a Custom Resource

Creating a Custom Resource in Minutes, Not Days

Confidence Through Comprehensive Testing

Standardize Infrastructure with Powerful Component Resources

Seamless Multi-Language Support and Sharing

Understanding Provider Schema

Get Started Today!

Pulumi Kubernetes Operator 2.0 is Now Generally Available!

What Is the Pulumi Kubernetes Operator?

The Evolution to 2.0

What’s New in GA?

Enhanced Logging Control

New Controller Events for Better Instrumentation

Workspace Reclaim Policy

See It in Action

Additional Resources

Start Using It Today

Pulumi Copilot is Now Available in VS Code

Video Walk Through

What is Pulumi Copilot?

The Pulumi Copilot REST API

How to Use Pulumi Copilot in Visual Studio Code

Key Use Cases

Infrastructure Code Generation

Terraform to Pulumi Migration

Resource Discovery

Error Resolution

Getting Started

Pulumi Kubernetes Operator 2.0

What is the Pulumi Kubernetes Operator?

What’s New in Pulumi Kubernetes Operator 2.0?

Installation

Security

Scalability

Stability

Customization and Extensibility

Operability

Walkthrough

Setup the GitRepository Source

Install a Pulumi Access Token

Create a Service Account

Create the Stack

Observe the Workspace

Observe the Updates

Observe the Stack

Delete the Stack

Migration

Conclusion

Announcing the Pulumi Visual Studio Code Extension

Getting Started

Install the Software

Debugging Pulumi IaC Programs