Running in circles on this: we have our own `Servi...
# kubernetes
Running in circles on this: we have our own
component resource. In our own abstraction, we create a NodePort based k8s
resource, retrieve the actual nodeport value from the service using apply and pass it on to a GKE specific
CRD. This is the code snippet:
Copy code
const healthPortNumber: pulumi.Input<number> = this.service.spec.apply((spec) => {
      const healthPort = spec.ports.find((port) => {
        return === 'health';
      if (healthPort) {
        return healthPort.nodePort;
      } else {
        return 4001;
We have a stack where the ports section of the
spec contains this (taken from the stack state):
Copy code
  "name": "health",
  "nodePort": 30449,
  "port": 4001,
  "protocol": "TCP",
  "targetPort": "health"
But we get
as the value for
. How is that possible??
What makes it even stranger: if we remove the service (commenting it) and redeploy again (uncommenting it), this code works on the new deployment.
And again, when updating the service with e.g. an additional annotation, the problem comes up again: no nodeport value. Is Pulumi not fetching the full state on update @gorgeous-egg-16927?
We had something simular, de deployed a k8s secret in a helm file with value X and then the chart had an init container to update it. Pulumi never saw the updated value, like it was “cached” or something. We fixed it by manually getting it
Copy code
const secret = fabricCa.getResource('v1/Secret', 'default', 'ca-tls-cert');

// <>
const updatedSecret = k8s.core.v1.Secret.get('tlssecret',, {
  dependsOn: [fabricCa],

export const data = => data);
apply on “secret” = old version apply on “updatedSecret” = new version
not sure if it helps your issue, but the ability to force a fetch from the cluster might help as workaround
This is well worth the try. Tnx for the suggestion @proud-pizza-80589
BTW @proud-pizza-80589 did you ever file a Github issue regarding this?
No, i figured it works as designed because we are updating the secret outside of pulumi’s process, it cannot really know about the changed value
ok. That is clearly not the case for me. Also the service is deployed by Pulumi.
One option might be to do a get on the secret after it is created. If the nodeport is automatically allocated by k8s and not in your spec then I don’t know if pulumi does a lookup of the full resource if it was created since it is updated outside of it’s creation.
@fast-dinner-32080 the nodeport value is visible in the Pulumi state with the correct value, after the k8s
is created. Why don’t I get this value (which remains unchanged) if I just add e.g. an annotation?
Hmm, that is odd. It sounds to me like the
code is running prior to the
value resolving (it’s usually set by the cluster). This seems like a possible oversight in the await logic for Service resources. If you look at you’ll notice that the
isn’t considered as part of the readiness check.
@billowy-army-68599 Any ideas for workarounds here?
@gorgeous-egg-16927 @billowy-army-68599 should I file a GH issue for this?
Sorry lots of plates spinning at the moment. Yes a GitHub issue would great at thank you