Commit graph

11 commits

Author SHA1 Message Date
Mehdi El Gueddari
d5db024763 kubernetes: use apps/v1 for Deployment (#166)
In certain situations (see details below), the deployment to Kubernetes fails with:

> "The Deployment [DEPLOYMENT_OBJECT] is invalid: [...] `selector` does not match template `labels`".

This is caused by the K8S Deployment manifests missing an explicit `selector` value.

This commit:
* adds explicit `selector` values for all Deployment objects.
* bumps the K8S API from the deprecated `extensions/v1beta1` version to the stable `apps/v1` version. This version made the `selector` property of the Deployment a required value, preventing any issues with missing selectors in the future.

This change is backwards compatible with existing deployments of the microservices demo app. I.e. you should be able to pull this change and run `skaffold run` against an existing deployment of the app without issues.

This will not however resolve the issue for existing deployments. Selectors are immutable and will therefore retain their current defaulted value. You should run `skaffold delete` followed by `skaffold run` after having pulled this change to do a clean re-deployment of the app, which will resolve the issue.

**The nitty-gritty details**

In the `extensions/v1beta1` version of K8S API (the version that was used by this project), the `selector` property of a Deployment object is optional and is defaulted to the labels used in the pod template. This can cause subtle issues leading to deployment failures. This project, where Deployment selectors were omitted, is a good example of what can go wrong with defaulted selectors.

Consider this:

1. Run `skaffold run` to build locally with Docker and deploy.

Since the Deployment specs don't have explict selectors, they will be defaulted to the pod template labels. And since skaffold adds additional labels to the pod template like `skaffold-builder` and `skaffold-deployer`, the end-result will be a selector that looks like this:

> app=cartservice,cleanup=true,docker-api-version=1.39,skaffold-builder=local,skaffold-deployer=kubectl,skaffold-tag-policy=git-commit,tail=true

So far, so good.

2. Now run `skaffold run -p gcb --default-repo=your-gcr-repo` to build on Google Cloud Build instead of building locally.

This will blow up when attempting to deploy to Kubernetes with an error similar to:

> The Deployment "cartservice" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"skaffold-builder":"google-cloud-build", "profiles"="gcb", "skaffold-deployer":"kubectl", "skaffold-tag-policy":"git-commit", "docker-api-version":"1.39", "tail":"true", "app":"cartservice", "cleanup":"true"}: `selector` does not match template `labels`

(and the same error for every other deployment object)

This is because the skaffold labels that were automatically added to the pod template have changed to include references to Google Cloud Build. That normally shouldn't be an issue.

But without explicit Deployment selectors, this results in the defaulted selectors for our Deployment objects to have also changed. Which means that the new version of our Deployment objects are now managing different sets of Pods. Which is thankfully caught by kubectl before the deployment happens (otherwise this would have resulted in orphaned pods).

In this commit, we explicitely set the `selector` value of all Deployment objects, which fixes this issue. We also bump the K8S API version to the stable `apps/v1`, which makes the `selector` property a required value and will avoid accidently forgetting selectors in the future.

More details if you're curious:

* Why defaulted Deployment selectors cause problems: https://github.com/kubernetes/kubernetes/issues/26202
* Why Deployment selectors should be (and were made) immutable: https://github.com/kubernetes/kubernetes/issues/50808
2019-03-04 10:52:55 -08:00
rghetia
54f0a8d058 add jaeger support for productcatalog and shipping. (#126) 2019-01-22 09:56:39 -08:00
Dave Stanke
8dabe7ff94 remove gcr repo name from images (#98)
This removes hardcoded GCP project name from images and requires an explicit repository flag to skaffold. Also updating the cloudbuild.yaml for staging with the gcr.io/k8s-skaffold/skaffold image.

Fixes #17.
2018-12-03 14:19:12 -08:00
Ahmet Alp Balkan
1bab006af1
grpc: implement health check in go services (#27)
Also locked grpc-go to =1.14 exact version.
See grpc/grpc-go#2314 and grpc/grpc-go#2313 for reference
2018-09-20 10:31:31 -07:00
Ahmet Alp Balkan
db40889ad0
Change gcr projectID in images
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
2018-08-04 11:23:35 -07:00
Ahmet Alp Balkan
3493cc1cb4
Add more license headers
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
2018-07-25 21:25:27 -07:00
Ahmet Alp Balkan
03182151ee Add gcr.io/istio-next to image names
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
2018-07-07 17:14:52 -07:00
Ahmet Alp Balkan
77fac95443 k8s: add terminationGracePeriodSeconds to some
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
2018-06-29 11:08:10 -07:00
Ahmet Alp Balkan
781cdaed9e k8s: add liveness/readiness probes
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
2018-06-29 11:08:10 -07:00
Ahmet Alp Balkan
3ae9448346 k8s: add resource limits to deployments
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
2018-06-22 09:35:30 -07:00
Ahmet Alp Balkan
98ac7e3a10 add kubernetes manifets and skaffold.yaml
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
2018-06-21 14:03:04 -07:00