A Kubernetes Deployment declares the recipe for running an application’s containers: which image to use, how to configure it, and how many replicas should be available. Kubernetes creates replacement instances to maintain the desired replica count. Unlike an individual Pod, the Deployment remains available to inspect when its containers fail. section 2.1.2 section 2.3.1 section 2.3.2
A Deployment connects several operational decisions:
- Its container configuration can include environment variables and resource allocations; readiness and liveness probes report whether the container is ready or running. section 2.1.2 section 2.3.1
- Its update strategy controls version or configuration changes. RollingUpdate incrementally replaces Pods to minimize downtime; Recreate shuts them all down before creating replacements. section 2.3.2
- It manages ReplicaSets, which handle the requested replicas and participate in rolling updates; operators usually work with the Deployment instead. section 2.3.2 section 2.3.3
Inspect and scale the Conference frontend
Run `kubectl get deployments` to check READY, UP-TO-DATE, and AVAILABLE counts. Then run `kubectl describe deploy conference-frontend-deployment` to inspect the image, desired and available replicas, update strategy, Pod template, and events. If the requested replica count is not met, those details help locate the problem. To add a frontend instance, run `kubectl scale --replicas=2 deployments/conference-frontend-deployment`; listing the Pods should then show two frontend replicas. section 2.3.1 section 2.3.2 section 2.3.3
Listing 2.3 Describing a deployment to see its details
> kubectl describe deploy conference-frontend-deployment
Name: conference-frontend-deployment
Namespace: default
CreationTimestamp: Tue, 27 Jun 2023 08:21:21 +0100
Labels: app.kubernetes.io/managed-by=Helm
Annotations: deployment.kubernetes.io/revision: 1
meta.helm.sh/release-name: conference
meta.helm.sh/release-namespace: default
Selector: app=frontend
Replicas: 1 desired | 1 updated | 1 total | 1 available #1
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=frontend
Containers:
frontend:
Image: salaboy/frontend-go... #2
Port: 8080/TCP
Host Port: 0/TCP
...
...
Environment: #3
AGENDA_SERVICE_URL: agenda-service.default.svc.cluster.local
C4P_SERVICE_URL: c4p-service.default.svc.cluster.local
NOTIFICATIONS_SERVICE_URL: notifications-service.default.svc.cluster.local
KAFKA_URL: conference-kafka.default.svc.cluster.local
POD_NODENAME: (v1:spec.nodeName)
POD_NAME: (v1:metadata.name)
POD_NAMESPACE: (v1:metadata.namespace)
POD_IP: (v1:status.podIP)
POD_SERVICE_ACCOUNT: (v1:spec.serviceAccountName)
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: conference-frontend-deployment-<ID> (1/1 replicas created)
Events: #4
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 48m deployment-controller Scaled up replica set conference-frontend-deployment-59d988899 to 1
The described frontend Deployment shows one desired and available replica, a RollingUpdate strategy, and the container image and port in its Pod template. section 2.3.2
A Deployment also supplies connection settings to its Pods. For example, the Conference Call for Proposals service receives PostgreSQL connection values through environment variables backed by a Kubernetes Secret; its database endpoint depends on the installed Helm chart’s release name. Changing the Pod template’s configuration triggers a rolling update. section 5.1.2 section 2.3.3
Listing 5.1 Environment variables to connect to application infrastructure (PostgreSQL)
- name: KAFKA_URL
value: <KAFKA SERVICE URL>
- name: POSTGRES_HOST
valueFrom:
secretKeyRef:
name: <POSTGRESQL SECRET NAME>
key: postgres-url
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: <POSTGRESQL SECRET NAME>
key: postgres-password
The environment-variable configuration shows Kafka’s service URL alongside PostgreSQL values read from Secret keys. section 5.1.2
