Comments (7)
from pilot.
This is what I mean by 1):
Here is a typical case for a pod deployment. Let's say I'm upgrading my container image from v1 to v2. The deployment has a spec for a pod. This spec should have a field "version" and value v1 in the first iteration and value v2 for the second. Istio then should identify two service tags "version=v1" and "version=v2". The only way to control the service tag is using this Deployment: I cannot change an individual pod assignment from v1 to v2 (Deployment would kill it due to a spec change). I cannot create a new version v3 without modifying Deployment. So there'd be tight coupling between Deployments and service tags.
from pilot.
We are going with pod label selectors as the source of truth for the service tag information.
The reason is the interoperability with kubernetes deployments/replica sets.
There are two items left to work out:
- pod version reassignment. Kubernetes discourages modifying live pod labels (see discussions openshift/origin#11954).
- do we need two deployments or a single deployment with some annotations is sufficient for A/B testing type experiments.
from pilot.
Forgive me if this was already resolved elsewhere, but if nothing else I wanted to follow-up for my own understanding.
Doesn't A/B, canary, blue/green, etc. imply the creation of a new pod with new image? Why wouldn't this pods be created with the new version label vs. modifying existing labels.
The two deployment method seems to be a well established pattern as described by canary-deployments. Any reason this pattern wouldn't work for A/B, blue/green?
from pilot.
We want to gradually rollout config versions in the future (e.g. Mixer config). It should be possible apply a runtime config change without restarting application containers.
from pilot.
Perhaps it's worth considering application (i.e. service tag) and configuration (i.e. mixer) versioning independently first?
-
For application versioning, multiple deployments seems reasonable (necessary?) since a new pod/container needs to be created anyway.
-
For configuration versioning without pod restarts, incrementally adding additional labels to already created pods in a deployment might still work, but would require closely monitoring pod resources and re-labeling to account for lack of pod durability, scaling, etc. These configuration version labels would need to be added outside of the deployment spec otherwise, as you noted, the deployment controller will kill the pod. Alternatively, we maintain our own registry to track which pods belong to a specific configuration version, but that also requires tracking pod resources and duplicates state vs. maintaining the state in k8s itself via labels.
With regards to re-labeling pods, openshift/origin#11954 seems to be referring to changing the labels on the {Deployment,Replication}Controller and not necessarily on the pods themselves. I didn't see anything that discouraged adding additional labels to pods beyond what the controller expects, but maybe I missed something?
MarkRx commented on Nov 17, 2016 • edited
I have been able to change the labels on the running pods. If however I change the label on the dc / replication controller new pods continue to use the old label.
from pilot.
It's possible to update labels on live pods. I think it might cause issues with some controllers that watch for the pod specs, and my impression was that it's not recommended and not well specified.
We can also use annotations instead of labels. They are more flexible and don't interfere with replica sets or deployments. Annotations are designed specifically for our purpose.
Manager will keep track of both labels and annotations on all pods, to associate service instances with service tags/versions.
The config ID can be inside the user-supplied spec, in case the pod version and config version need to be updated at the same time.
The real blocker is not having Mixer config or config ID yet. So we are not looking into this until we get better understanding of how Mixer configuration works.
from pilot.
Related Issues (20)
- istioctl not defaulting ns to "default" HOT 1
- Sidecar injection with mutating webhooks HOT 4
- Tests :Sidecar injection with mutating webhooks HOT 3
- Istio injection is not working for modified Deployments. HOT 6
- Ingress with host network HOT 1
- Request Headers Route Rule with composite services does not work HOT 1
- handling service registry client errors HOT 3
- Redirecting all ingress http traffic to https HOT 1
- Relational database adapter for Pilot config store HOT 10
- Diego BBS adapter for Pilot platform data HOT 12
- bazel 0.7 - make setup fails with bazel error on macOS HOT 12
- Use readable cluster names in stats HOT 4
- Build fails on Intel for Istioctl(pilot) HOT 14
- destination.labels is ignored in weighted rule HOT 4
- fails to create mixer configs when namespace field is empty
- Compute Envoy config eagerly rather than on-demand HOT 33
- istioctl kube-inject doesn't work when my pod has 2 containers HOT 2
- Add a script to query pilot for proxy configurations HOT 1
- gRPC-web HOT 1
- How to access the external services when istio with sidecar injected. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pilot.