Kubernetes Deployments: The Ultimate Guide - Semaphore - 1 views
-
Continuous integration gives you confidence in your code. To extend that confidence to the release process, your deployment operations need to come with a safety belt.
-
these Kubernetes objects ensure that you can progressively deploy, roll back and scale your applications without downtime.
-
A pod is just a group of containers (it can be a group of one container) that run on the same machine, and share a few things together.
- ...34 more annotations...
-
the containers within a pod can communicate with each other over localhost
-
From a network perspective, all the processes in these containers are local.
-
we can never create a standalone container: the closest we can do is create a pod, with a single container in it.
-
Kubernetes is a declarative system (by opposition to imperative systems).
-
All we can do, is describe what we want to have, and wait for Kubernetes to take action to reconcile what we have, with what we want to have.
-
In other words, we can say, “I would like a 40-feet long blue container with yellow doors“, and Kubernetes will find such a container for us. If it doesn’t exist, it will build it; if there is already one but it’s green with red doors, it will paint it for us; if there is already a container of the right size and color, Kubernetes will do nothing, since what we have already matches what we want.
-
The specification of a replica set looks very much like the specification of a pod, except that it carries a number, indicating how many replicas
-
What happens if we change that definition? Suddenly, there are zero pods matching the new specification.
-
the creation of new pods could happen in a more gradual manner.
-
the specification for a deployment looks very much like the one for a replica set: it features a pod specification, and a number of replicas.
-
Deployments, however, don’t create or delete pods directly.
-
When we update a deployment and adjust the number of replicas, it passes that update down to the replica set.
-
When we update the pod specification, the deployment creates a new replica set with the updated pod specification. That replica set has an initial size of zero. Then, the size of that replica set is progressively increased, while decreasing the size of the other replica set.
-
we are going to fade in (turn up the volume) on the new replica set, while we fade out (turn down the volume) on the old one.
-
During the whole process, requests are sent to pods of both the old and new replica sets, without any downtime for our users.
-
A readiness probe is a test that we add to a container specification.
-
Kubernetes supports three ways of implementing readiness probes:Running a command inside a container;Making an HTTP(S) request against a container; orOpening a TCP socket against a container.
-
When we roll out a new version, Kubernetes will wait for the new pod to mark itself as “ready” before moving on to the next one.
-
If there is no readiness probe, then the container is considered as ready, as long as it could be started.
-
MaxSurge indicates how many extra pods we are willing to run during a rolling update, while MaxUnavailable indicates how many pods we can lose during the rolling update.
-
Setting MaxUnavailable to 0 means, “do not shutdown any old pod before a new one is up and ready to serve traffic“.
-
Setting MaxSurge to 100% means, “immediately start all the new pods“, implying that we have enough spare capacity on our cluster, and that we want to go as fast as possible.
-
kubectl rollout undo deployment web
-
the replica set doesn’t look at the pods’ specifications, but only at their labels.
-
A replica set contains a selector, which is a logical expression that “selects” (just like a SELECT query in SQL) a number of pods.
-
it is absolutely possible to manually create pods with these labels, but running a different image (or with different settings), and fool our replica set.
-
Selectors are also used by services, which act as the load balancers for Kubernetes traffic, internal and external.
-
internal IP address (denoted by the name ClusterIP)
-
during a rollout, the deployment doesn’t reconfigure or inform the load balancer that pods are started and stopped. It happens automatically through the selector of the service associated to the load balancer.
-
a pod is added as a valid endpoint for a service only if all its containers pass their readiness check. In other words, a pod starts receiving traffic only once it’s actually ready for it.
-
In blue/green deployment, we want to instantly switch over all the traffic from the old version to the new, instead of doing it progressively
-
We can achieve blue/green deployment by creating multiple deployments (in the Kubernetes sense), and then switching from one to another by changing the selector of our service
-
kubectl label pods -l app=blue,version=v1.5 status=enabled
-
kubectl label pods -l app=blue,version=v1.4 status-
-
"Continuous integration gives you confidence in your code. To extend that confidence to the release process, your deployment operations need to come with a safety belt."
