For

k8s.rbac.v1.ClusterRole

, in

k8s.rbac.v1.PolicyRuleArgs

, if I omit setting

api_groups

, is it equivalent to:

rules:
- apiGroups: [""] # "" indicates the core API group

Hello peeps.. I just posted this to twitter and wanted to also ask here...

Twitter peeps, I need help.

I have an http://ASP.NET Core Host serving gRPC endpoints up. This host is hosted in Kubernetes behind a nginx-ingress-controller. Ingress Controller terminates HTTPS. For the life of me, I cannot get to the gRPC service endpoints.

I'm hoping to find someone whom I can talk to, or point me at examples. My google-foo for this is failing terribly.

Thanks in advance.

Using

k8s.rbac.v1.ClusterRole

with Azure AKS, I get this even while recreating a stack from scratch (destroy, then up):

Diagnostics:
  <kubernetes:rbac.authorization.k8s.io/v1:ClusterRole> (clusterRole-storage):
    error: resource system:azure-cloud-provider was not successfully created by the Kubernetes API server : <http://clusterroles.rbac.authorization.k8s.io|clusterroles.rbac.authorization.k8s.io> "system:azure-cloud-provider" already exists

Is this expected? What should I be doing ideally?

Is there a way to suppress a k8s Provider from putting the kubeconfig in the logs in plaintext?

Anyone else experience extreme slowness when deploying larger Helm charts? For example, I’m deploying gloo edge overnight and it took 2h47m. I looked into adding pulumi.com/skipAwait annotations but I’m not sure it’s speeding it up (still running). Deploying the same helm chart with terraform only takes 37 seconds.

This message was deleted.

Hi guys 👋 I’m investigating moving away from an in-house deployment tool that uses google-go-gcp SDK and k8s SDK to using Pulumi as one-library-to-rule-them-all solution.

I have a question which is the reason why we are making this move and why we are considering Pulumi. In our current solution, we need to use different k8s APIs / go packages to deal with the different k8s API changes/deprecations (e.g. Ingress in networking/v1beta vs Ingress in networking/v1) and this is causing us to have different code branches based on k8s server versions.

Is this something that Pulumi can internalise? Is Pulumi clever enough to determine which k8s APIs to use based on k8s server version?

Can I clone a running stack from one cluster to another? What would be the Pulumi API to attempt this? Could I clone a deployed running stack in the Pulumi service, and rewire everything? Is there a negative(?) to

pulumi refresh

which would presumably refresh the cluster state based off the Pulumi stack state? I want to copy over a bunch of running pods from my toy cluster to a live cluster, and skip the deployment-from-scratch workflow altogether; what's interesting to me is the actual state of the app, I want to keep what I was tinkering with in the toy cluster (memory state, PVCs). Kind of like freezing a VM and moving it to another hypervisor, but for an already deployed k8s app... A non-me use-case could be to clone the state of an k8s app and send it as-is to a friend to run on their cluster (many assumptions withstanding) Maybe sething at the container/pod/resource layer can be used? I suppose I could keep searching for DRP, whole cluster import/export/backup patterns, not sure if this is a valid use-case in other contexts... Maybe I need to think differently about all this; feedback appreciated :-)

I’ve kinda been avoiding the point and just making sure I pass all my K8s resources a

provider

, but is there an easier way?

I’m thinking a transformation?

Just a 10PM thought without checking the code; I assumed this would be possible as I already have apiVersion transforms

Does the Pulumi Operator work without the Pulumi hosted service?

Hi everybody. Does anybody have a success story of using Pulumi as an ArgoCD plugin for pure Yaml (k8s objects) generation? This comment on Github got some attention, but I haven’t been able to find any working example 😪

👋 I’ve been seeing pulumi dependency graph problems when using

k8s.yaml.ConfigFile

. In simplified terms, I have two yaml files:

foo.yaml

and

bar.yaml

, each of which defines multiple resources. The resources in

bar.yml

depend on those in

foo.yaml

. Thus, my pulumi (typescript) code looks something like:

const foo = new k8s.yaml.ConfigFile("foo", { file: "foo.yaml" });
const bar = new k8s.yaml.ConfigFile("bar", { file: "bar.yaml" }, { dependsOn: foo });

however, when pulumi runs the update, it starts creating the resources under

bar

first.. and of course they fail. it actually starts retrying them 5 times, and sometimes they’ll eventually succeed because the resources in

foo

got created in the meantime, but the behavior is non-deterministic and fails very often. Do you know why pulumi isn’t waiting on

foo

resources to be created before creating the resources in

bar

?

is it correct that if i establish a k8s provider using an eks cluster output lifted as input to the provider, this should create implicit dependency chain ? and then everything i use that provider as an option for also inherits that implicit dependency ??? ie -

# create cluster resource
    eks_cluster = aws.eks.Cluster("itplat-eks-cluster", opts=provider_opts, **eks_cluster_config)
 
    k8s_use1_provider = k8s.Provider(
        k8s_use1_provider_name,
        cluster=eks_cluster.arn,
        context=eks_cluster.arn,
        enable_dry_run=None,
        namespace=None,
        render_yaml_to_directory=None,
        suppress_deprecation_warnings=None,
    )

    # lets have a go at creating a "crossplane-system" namespace
    crossplane_namespace = k8s.core.v1.Namespace(
        "crossplane-system", opts=pulumi.ResourceOptions(provider=k8s_use1_provider), metadata=k8s.meta.v1.ObjectMetaArgs(name="crossplane-system")
    )

this makes namespace dependent on provider which is dependent on eks_cluster ??

Not technically a Pulumi question, but maybe someone here has an idea; I have 

nginx-ingress

 deployed with Pulumi (helm chart) in an EKS cluster sitting in front of Node.js pods, and every so often I get a 

upstream prematurely closed connection while reading response header from upstream

 and I have no clue why. Does that ring a bell to anyone?

I was looking for an example in Go for how to create a Deployment that references a ConfigMap (and/or Secret), but couldn’t seem to find any (I could find a bunch of Typescript examples). Is there a quick pointer? For example, say I have:

myConfigMap, err := corev1.NewConfigMap(ctx, "my_config_map", &corev1.ConfigMapArgs{ ...

How do I reference that in my Deployment (in this in

EnvFrom

):

...
							EnvFrom: corev1.EnvFromSourceArray{
								&corev1.EnvFromSourceArgs{
									ConfigMapRef: &corev1.ConfigMapEnvSourceArgs{
										Name: ... what goes here ? ...
									},
								},
...

(This is with Pulumi 3 btw)

Is there a way when creating a service to tell it to not wait for any pods to be ready? Specifically, we create our services prior to creating the Deployments/DaemonSets, as we depend on the service environment variable injection to happen into the later-created pods. With Pulumi, I’ve expressed the dependency (i.e. the Deployment has a DependsOn the Service objects), but the Service itself never becomes ready as it is in stuck in the “Finding Pods to direct traffic to” stage (1/3). I’d like to tell it to not do that.

This is more of a pattern question, but what would be a good way to do something like: 1. Create a namespace 2. Instantiate a provider that is defaulted to that namespace 3. Use that provider for all subsequent resources

Also, separately, I found what are likely two small bugs in the

kube2pulumi

online site - should I just open GitHub issues for them?

hello Pulumi team, I updated my ticket with conclusive findings on a bug with secret state encryption causing

pulumi preview --diff

to not print out anything useful

Is there a good way to handle “dependencies” within a Helm chart deployed via Pulumi? In this specific case, I am deploying the Superset Helm chart, and it has some implicit dependencies between some ConfigMap objects and Jobs/Deployments, so if I update the ConfigMap (via the passed in

values

), things don’t get re-run. In a normal setting I’d just explicitly declare the dependencies (or have it be implicit via the resources), but the Helm chart is a single unit, and not clear to me if I can do it via a Transformation.

I miss the fast-feedback of TDD workflows in pulumi land, and I remember seeing some test driven examples (I think compliance-related, ensuring some resources are of a specific type, kind of stuff) Is anyone building their stacks in a test-driven way? I'm planning to refactor one stack into two, and I'd like an automatic test to tell me that everything's green. I believe I could use the outputs/exports to have the stacks inter-communicate(?) What does "test-driven" mean in a cloud engineering context anyway? I'm thinking I should be able to boot-up an Ubuntu VM with microk8s in it, boot up the k8s pulumi stack, run some tests, and then tear everything down. Later this could fit into some CI pipeline. (I'm working locally, not on a public cloud, and the feedback loop is painfully slow)

for some reason, my core.v1.Secret resource wants to be replaced on every pulumi run arguing that "data" has changed (it has not) - how do I debug this?

Is this the best way to get the kubeconfig from an EKS cluster in Go to pass to another provider? https://github.com/pulumi/examples/blob/e3b4e1734fc827451e3bccf623468c320015a084/aws-go-eks/main.go#L143

hi. in here https://www.pulumi.com/docs/guides/adopting/from_kubernetes/ it shows

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

// Deploy the latest version of the stable/wordpress chart.
const wordpress = new k8s.helm.v3.Chart("wpdev", {
    repo: "stable",
    chart: "wordpress",
    version: "9.0.3",
});

// Export the public IP for WordPress.
const frontend = wordpress.getResource("v1/Service", "wpdev-wordpress");
export const frontendIp = frontend.status.loadBalancer.ingress[0].ip;

Is there a way to get this code to run as is or must it be modified with apply like so

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

// Deploy the latest version of the stable/wordpress chart.
const wordpress = new k8s.helm.v3.Chart("wpdev", {
    repo: "stable",
    chart: "wordpress",
    version: "9.0.3",
});

// Export the public IP for WordPress.
const frontend = wordpress.apply(wordpress => wordpress.getResource("v1/Service", "wpdev-wordpress"));
export const frontendIp = frontend.apply(frontend=>frontend.status.loadBalancer.ingress[0].ip);

Thanks

So, I accidentally deleted a deployment managed by Pulumi

what steps do I have to take to reconcile the state?