Skip to content

Latest commit

 

History

History
executable file
·
128 lines (97 loc) · 4.59 KB

File metadata and controls

executable file
·
128 lines (97 loc) · 4.59 KB

Deployments

Deployments is a higher-level resource that makes managing Pods easier. Manifests for deployments resembles Pod manifests since it uses the same fields.

  • Declare a desired state for your Pods, and Deployments will do the work to bring your cluster to the desired state
  • Application scales by creating more replicas
  • When any changes are done on the resources, the deployment controller converges the actual state with the desired state
  • Configurable rolling update behavior to control how many Pods in a Deployment are updated

A Deployment controller constantly monitors the desired state of the Deployment and the state of the Kubernetes cluster and reconciles the cluster state with the desired state you provide the Deployment.

The Deployment manifest includes:

  • replicas that let you specify how many copies of the Pod you want the Deployment to create

  • selector, which is a Pod label selector that allows the Deployment controller to track the status of all the Pods in the Deployment. This is one example of how Kubernetes uses selectors. The matchLabels mapping defines an equality condition similar to how you would write "app=microservices" using kubectl.

  • template is a template for the Pods that will be created. The template provides the desired behavior of each Pod and is essentially the same as an individual Pod manifest. Notice the label that the Deployment selector uses is applied to the Pod (app: microservices). This is required for the Deployment to track its Pods.

At a very high-level view:

Below is an example of a Deployment manifest:

# data-tier.yml

apiVersion: apps/v1 # apps API group
kind: Deployment
metadata:
  name: data-tier
  namespace: deployment
  labels:
    app: microservices
    tier: data
spec:
  replicas: 1
  selector:
    matchLabels:
      tier: data
  template:
    metadata:
      labels:
        app: microservices
        tier: data
    spec: # Pod spec
      containers:
      - name: redis
        image: redis:latest
        imagePullPolicy: IfNotPresent
        ports:
          - containerPort: 6379  

To create the deployment:

kubectl apply -f data-tier.yml

To get details on the Deployment, use the describe command.

$ kubectl describe deployments data-tier  

Name:                   data-tier
Namespace:              deployment
CreationTimestamp:      Thu, 29 Dec 2022 16:18:28 +0000
Labels:                 app=microservices
                        tier=data
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               tier=data
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=microservices
           tier=data
  Containers:
   redis:
    Image:        redis:latest
    Port:         6379/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   data-tier-d45bbd7dc (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  11s   deployment-controller  Scaled up replica set data-tier-d45bbd7dc to 1

Here are some of the important highlights of the output:

  • StrategyType The strategy specified in our Deplyment is RollingUpdate, which means when you specify a new desired state for the Deployment's Pods, the update will be incrementally rolled out to all of the Pods.

  • RollingUpdateStrategy controls rolling updates by creating an upper bound and lower bound on the total number of Pods in the Deployment:

    • max unavailable: The maximum number of Pods that can be unavailable during the update.
    • max surge: The maximum number of Pods that can be scheduled above the desired number of Pods.

To learn more abour rollouts, check out Rollouts and Rollbacks.

To see deployments in action, check out this lab.

To learn more about Deployments and StatefulSets using Persistent Volumes in AWS, check out Amazon EKS - Persistent Volumes page.


Back to first page