pulumi-community #kubernetes

broad-dog-22463

10/01/2020, 9:19 PM

What do you need the experience to be?

broad-dog-22463

10/01/2020, 9:20 PM

The output of that command is stable as long as it’s not a container that is changed outside of Pulumi’s control

flat-insurance-25294

10/01/2020, 9:27 PM

Ok, I think I get it. You’re literally relying on Docker and nothing more - which is what I would expect (so 👍 )

broad-dog-22463

10/01/2020, 9:28 PM

Yessir!

broad-dog-22463

10/01/2020, 9:28 PM

If that specific thing isn’t working for you then it’s 100% a bug we need to fix

flat-insurance-25294

10/01/2020, 9:28 PM

My issue was I couldn’t tell from the docs what the output of

buildAndPushImage().image()

does when it’s used in conjunction with

awsx/kubernetes/EKS

Inside a

Deployment/Pod

manifest for containers.

Copy code

spec: {
                containers: [{
                    image, // **Use the image built above**
                }],

I know the string would be something like

<http://012345678901.dkr.ecr.us-west-2.amazonaws.com/my-repo-e2fe830:latest|012345678901.dkr.ecr.us-west-2.amazonaws.com/my-repo-e2fe830:latest>

Where parts of that is based on AWS meta-data like ID, region etc.

broad-dog-22463

10/01/2020, 9:29 PM

Yeah that metadata is from the state

broad-dog-22463

10/01/2020, 9:29 PM

broad-dog-22463

10/01/2020, 9:29 PM

It’s part of the inputs / outputs of the image resource

flat-insurance-25294

10/01/2020, 9:31 PM

Right, the issue here is if replica count changes and the image is generated as:

<http://amazonaws.com/my-repo-e2fe830:latest|amazonaws.com/my-repo-e2fe830:latest>

each time. The newer pods will run a new image if Docker failed to understand that there is no need for a new “image push” - that’s not on Pulumi though. That can happen for loads of reasons, e.g poorly made Dockerfile, etc.

broad-dog-22463

10/01/2020, 9:32 PM

Yeah :/ that’s the pitfalls of using latest I’m afraid - I always suggest using tag names specifically

flat-insurance-25294

10/01/2020, 9:32 PM

Yep. It’s not an issue on master, but our staging and pr-environments.

flat-insurance-25294

10/01/2020, 9:33 PM

Master has manually defined names (tags) from approved staging builds. But sometimes for a PR we want to test upping the replica count without redeploying a new image. Since we go through a CICD, it will build a new image, even though we just changed a replica count. I guess the real solution is using kubectl CLI to change just the replica count - that’s fine since we have access to pr environments via cli (not master or staging)

flat-insurance-25294

10/01/2020, 9:34 PM

@broad-dog-22463 Thanks for explaining and being patient!

broad-dog-22463

10/01/2020, 9:36 PM

Any time!

quaint-electrician-41503

10/02/2020, 6:37 PM

Hello, I'm new to Pulumi but I have gotten beat down yesterday trying to deploy a helm chart. From the helm command I normally

helm -f values.yaml name /path/to/chart

quaint-electrician-41503

10/02/2020, 6:38 PM

I'd like to know how I can load a kubernetes yaml file and apply the configuration of

values.yaml

from

LocalChartOpts

. I found

kubernetes.yaml

but can't seem to get the proper values from E.G.

ConfigFile

quaint-electrician-41503

10/02/2020, 6:41 PM

I tried to for example set kubernetes config in a pulumi yaml file but due to the nested hierarchical yaml format I couldn't figure out how to load that configuration and try to apply via that route. Any pulumi kube experts in here that can help me reason about this, understand limitations, and sort this out?

broad-dog-22463

10/02/2020, 6:42 PM

this may be of help on how to deploy a helm chart with Pulumi - https://github.com/pulumi/pulumi-kubernetes/blob/master/tests/sdk/nodejs/istio/step1/charts/istio-init/README.md

quaint-electrician-41503

10/02/2020, 7:18 PM

Thanks @broad-dog-22463, I am looking through that repo. I'm trying to understand facets of deploying helm charts with Pulumi. I'd like to seperate the configuration of the helm chart from IE the provisioning program which seems to be a primary goal of most pulumi configuration. However due to differences in kubernetes yaml, I haven't yet found an ideal option. One thing I was considering was keeping the helm chart configurations in their natural form and trying to apply them with your api. However for some feature like

helm -f values.yaml name /path/to/chart

which is natural via helm, I cannot IE apply

ConfigFile

for the values argument of

LocalChartOpts

miniature-leather-70472

10/05/2020, 11:13 AM

I'm trying to deploy a Helm chart using Pulumi component resource, I've got a values dictionary I am passing to the resource, but one of the values it needs is the name of the container registry to use, which is something I may create in my template, so the value is an Input<string> rather than just a string. This fails because the container registry name is not passed correctly, because it is an Input<T> any way to deal with this?

limited-rainbow-51650

10/06/2020, 12:49 PM

Copy code

~ kubernetes:apps/v1:Deployment: (update)
        [id=deployer-ut11s29w/deployer-activities-k8s-l0dmq9rt]
        [urn=urn:pulumi:development::deployer::kubernetes:apps/v1:Deployment::deployer-activities-k8s]
        [provider=urn:pulumi:development::deployer::pulumi:providers:kubernetes::default_2_6_1::a73e10a4-562a-40e2-9db1-61bb39736827]
      ~ spec: {
          ~ template: {
              ~ spec: {
                  ~ containers: [
                      - [0]: {
                              - args           : [
                              -     [0]: "osimis-deploy-activities"
                                ]
                              - env            : [
                              -     [0]: {
                                      - name : "TEMPORAL_FRONTEND_HOST"
                                      - value: "<redacted>"
                                    }
                                ]
                              - image          : "<redacted>"
                              - imagePullPolicy: "Always"
                              - livenessProbe  : {
                                  - exec               : {
                                      - command: [
                                      -     [0]: "/bin/sh"
                                      -     [1]: "-c"
                                      -     [2]: "ps -ef | grep osimis-deploy-activities"
                                        ]
                                    }
                                  - failureThreshold   : 2
                                  - initialDelaySeconds: 10
                                  - periodSeconds      : 10
                                  - successThreshold   : 1
                                  - timeoutSeconds     : 5
                                }
                              - name           : "activities-worker"
                              - readinessProbe : {
                                  - exec               : {
                                      - command: [
                                      -     [0]: "/bin/sh"
                                      -     [1]: "-c"
                                      -     [2]: "ps -ef | grep osimis-deploy-activities"
                                        ]
                                    }
                                  - failureThreshold   : 6
                                  - initialDelaySeconds: 5
                                  - periodSeconds      : 10
                                  - successThreshold   : 1
                                  - timeoutSeconds     : 5
                                }
                              - resources      : {
                                  - limits  : {
                                      - cpu   : "0.15"
                                      - memory: "120Mi"
                                    }
                                  - requests: {
                                      - cpu   : "0.1"
                                      - memory: "100Mi"
                                    }
                                }
                              - volumeMounts   : [
                              -     [0]: {
                                      - mountPath: "/etc/pulumi-deployer/osimisdockercreds.conf"
                                      - name     : "osimis-docker-hub-credentials"
                                      - subPath  : "osimisdockercredes.conf"
                                    }
                                ]
                            }
                    ]
                }
            }
        }
Resources:
    ~ 1 to update
    8 unchanged

I’m not confident in applying this. What is happening? Context: Pulumi v2.11.2 + Kubernetes provider 2.6.1

limited-rainbow-51650

10/06/2020, 12:49 PM

I have a local change adding an additional environment variable to the Pod

spec

of a

Deployment

. That’s the only change, and I’m also the only one working with this stack, with which I want to clarify that no other team member could have made any changes. When I do a

preview --diff

, it wants to delete the

containers

section of the Pod `spec`:

quiet-wolf-18467

10/07/2020, 11:14 AM

Is it possible to get a

k8s.yaml.ConfigFile

or Helm template as straight up YAML in the Pulumi code?

quiet-wolf-18467

10/07/2020, 11:14 AM

I'm working on Cluster API integrations and I need to store this YAML as data keys within ConfigMaps and Secrets 🙂

limited-rainbow-51650

10/07/2020, 11:54 AM

Continuing with this setup: https://pulumi-community.slack.com/archives/C019YSXN04B/p1601995800036200 I’m wondering if I bumped into a bug regarding persistence of state. The automation API is running in a docker container, so I attached a cluster role & rolebinding with a set of permissions which I deemed enough to roll out a git based project/stack. In a previous run, Pulumi complained it couldn’t watch for the pods associated with a StatefulSet. Indeed, the

pods

resource was not added to list of permissions. Meanwhile, the statefulset and the pods are up and running though. So I redeployed the automation app with more permissions and ran again. But now it bails out complaining that my statefulset already exists. Running

pulumi stack export

shows me indeed that my statefulset is not recorded in the state. /cc @gorgeous-egg-16927

bitter-application-91815

10/08/2020, 11:07 AM

Hey there, I have deployed all my apps to kubs via helm charts, how to get the ingress endpoints for the cluster, the examples i can find only mention how to get it via an app deployment and corresponding service instance.

bitter-application-91815

10/08/2020, 11:07 AM

Basically

bitter-application-91815

10/08/2020, 11:07 AM

kubectl get ing -n axiomdb

bitter-application-91815

10/08/2020, 11:08 AM

axiomdb of course being my particular namespace