limited-rainbow-51650
04/20/2021, 9:51 AMService
component resource. In our own abstraction, we create a NodePort based k8s Service
resource, retrieve the actual nodeport value from the service using apply and pass it on to a GKE specific BackendConfig
CRD. This is the code snippet:
const healthPortNumber: pulumi.Input<number> = this.service.spec.apply((spec) => {
const healthPort = spec.ports.find((port) => {
return port.name === 'health';
});
if (healthPort) {
return healthPort.nodePort;
} else {
return 4001;
}
});
We have a stack where the ports section of the Service
spec contains this (taken from the stack state):
{
"name": "health",
"nodePort": 30449,
"port": 4001,
"protocol": "TCP",
"targetPort": "health"
}
But we get undefined
as the value for healthPort.nodePort
. How is that possible??proud-pizza-80589
04/20/2021, 1:15 PMconst secret = fabricCa.getResource('v1/Secret', 'default', 'ca-tls-cert');
// <https://www.pulumi.com/docs/intro/concepts/resources/#resource-get>
const updatedSecret = k8s.core.v1.Secret.get('tlssecret', secret.id, {
provider,
dependsOn: [fabricCa],
});
export const data = updatedSecret.data.apply((data) => data);
limited-rainbow-51650
04/20/2021, 1:28 PMproud-pizza-80589
04/20/2021, 1:46 PMlimited-rainbow-51650
04/20/2021, 2:05 PMfast-dinner-32080
04/20/2021, 4:55 PMlimited-rainbow-51650
04/20/2021, 6:56 PMService
is created. Why don’t I get this value (which remains unchanged) if I just add e.g. an annotation?gorgeous-egg-16927
04/20/2021, 9:15 PMhealthPortNumber
code is running prior to the nodePort
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 https://www.pulumi.com/docs/reference/pkg/kubernetes/core/v1/service/#service you’ll notice that the nodePort
isn’t considered as part of the readiness check.limited-rainbow-51650
04/22/2021, 11:18 AMbillowy-army-68599
04/22/2021, 3:17 PMlimited-rainbow-51650
04/23/2021, 12:21 PM