Unit 3: Deploying Microservices - Subjective Questions

Containerization is a virtualization technique in which an application and its dependencies are packaged into an isolated, portable unit called a container. Containers share the host operating system kernel but run with isolated processes, file systems, and network environments.

Containerization is useful for microservices because it provides:

• Portability: The same container image can run consistently across development, testing, and production environments.
• Isolation: Each microservice can use its own libraries, runtime, and configuration without conflicting with other services.
• Fast startup: Containers start faster than virtual machines because they do not require a complete guest operating system.
• Independent deployment: Each microservice can be built, versioned, scaled, and released separately.
• Efficient resource usage: Containers have less overhead than virtual machines.
• Reproducibility: Immutable images reduce differences between environments and prevent the common problem of software working only on a developer's machine.

Containers and virtual machines provide isolation at different levels.

Conclusion: Containers are generally well suited to microservices because they support rapid deployment, efficient scaling, and independent packaging. Virtual machines may be preferred where stronger isolation or different operating system kernels are required.

Docker follows a client-server architecture consisting of the following components:

• Docker client: Accepts commands such as docker build, docker pull, and docker run. It communicates with the Docker daemon through the Docker API.
• Docker daemon: Runs on the Docker host and manages images, containers, networks, and volumes.
• Docker image: A read-only, layered template containing the application, runtime, libraries, and configuration needed to create a container.
• Docker container: A running or stopped instance of an image with a writable container layer.
• Docker registry: Stores and distributes container images. Docker Hub is a public registry, while organizations may operate private registries.
• Docker host: The machine on which the daemon and containers run.

When a user runs docker run, the client sends the request to the daemon. If the required image is unavailable locally, the daemon pulls it from a registry. The daemon then creates a writable container layer, configures networking and storage, and starts the specified application process.

A Dockerfile is a text file containing ordered instructions that Docker uses to build a container image.

• FROM: Selects the base image and normally begins a build stage. For example, FROM node:20-alpine.
• WORKDIR: Sets the working directory for subsequent instructions and for the container process.
• COPY: Copies files or directories from the build context into the image.
• RUN: Executes a command while building the image and stores the resulting changes in an image layer. It is often used to install dependencies.
• EXPOSE: Documents the network port on which the application is expected to listen. It does not publish the port by itself.
• ENV: Defines an environment variable available to later build instructions and to containers created from the image.
• CMD: Provides the default command or arguments executed when a container starts. Runtime arguments can override it.

Docker processes these instructions in order and uses build caching where possible. A well-designed Dockerfile produces a small, reproducible, and secure image.

A Dockerfile for a Python microservice can be written as follows:

dockerfile
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8080
CMD ["python", "app.py"]

Explanation:

• FROM selects a lightweight Python runtime.
• WORKDIR creates or selects /app as the working directory.
• The dependency file is copied separately so that Docker can reuse the dependency layer when source code changes.
• RUN installs the required Python packages without retaining the package download cache.
• The second COPY adds the application source code.
• EXPOSE 8080 documents the service port.
• CMD starts the microservice when the container runs.

Build command:

docker build -t catalog-service:1.0 .

Run command:

docker run -d --name catalog -p 8080:8080 catalog-service:1.0

The -t option assigns an image name and tag. The -d option runs the container in the background, while -p 8080:8080 maps host port 8080 to container port 8080.

A Docker image is composed of immutable layers. Instructions such as FROM, COPY, and RUN generally create layers. During a build, Docker can reuse an unchanged layer and its dependent cached result instead of executing the instruction again.

A Dockerfile can be optimized by:

• Ordering instructions carefully: Copy dependency manifests and install dependencies before copying frequently changing source files.
• Using small base images: Minimal or slim images reduce storage, download time, and attack surface.
• Using multi-stage builds: Build tools and temporary files remain in an intermediate stage rather than the final runtime image.
• Combining related commands: Package installation and cleanup can occur in one RUN instruction to avoid retaining unnecessary files in earlier layers.
• Adding a .dockerignore file: Exclude source-control data, logs, local dependencies, secrets, and build output from the build context.
• Removing caches and temporary artifacts: Retain only files required at runtime.
• Pinning important versions: Reproducible versions reduce unexpected changes.

These practices make image builds faster and final images smaller, more reproducible, and easier to secure.

A Docker image is an immutable, versioned template containing an application and its runtime dependencies. A Docker container is an instance created from that image.

Key differences include:

• An image is a read-only build artifact, whereas a container adds a writable layer at runtime.
• One image can create many containers.
• Images are built, tagged, pushed, and pulled; containers are created, started, stopped, restarted, and removed.
• An image represents packaged software, while a container represents an execution environment for that software.

An image registry provides centralized image storage and distribution. In a deployment workflow:

1. The CI system builds and tests an image.
2. The image is assigned an immutable tag, such as a release version or commit identifier.
3. The image is pushed to a registry.
4. Deployment systems authenticate to the registry and pull the required image.
5. Containers are created from the exact image version.

Registries also support access control, vulnerability scanning, retention policies, and image provenance.

Container orchestration is the automated management of containerized applications across a cluster of machines.

It solves several problems found in large microservice deployments:

• Scheduling: Places containers on suitable nodes according to resource requirements and constraints.
• Scaling: Increases or decreases the number of service instances based on demand.
• Self-healing: Replaces failed containers and reschedules workloads when nodes fail.
• Service discovery: Enables services to locate and communicate with one another without fixed IP addresses.
• Load balancing: Distributes requests among healthy service instances.
• Configuration management: Supplies environment-specific settings without rebuilding images.
• Secret management: Provides controlled access to credentials and other sensitive values.
• Rolling updates and rollback: Replaces application versions gradually and restores a previous version when necessary.
• Storage management: Attaches persistent storage to stateful workloads.

Without orchestration, administrators would have to coordinate these activities manually across many hosts, making deployment slower and more error-prone.

A Kubernetes cluster consists of a control plane and one or more worker nodes.

Control plane components:

• API server: Exposes the Kubernetes API, validates requests, and acts as the main communication entry point.
• etcd: A consistent distributed key-value store that holds cluster configuration and state.
• Scheduler: Selects a worker node for each unscheduled Pod by considering resources, constraints, affinity rules, and policies.
• Controller manager: Runs controllers that continuously reconcile actual cluster state with desired state.
• Cloud controller manager: Integrates Kubernetes with supported cloud infrastructure such as load balancers and nodes.

Worker node components:

• kubelet: Ensures that the containers described in Pod specifications are running and healthy on its node.
• Container runtime: Runs containers using software such as containerd or CRI-O.
• kube-proxy: Implements service networking and traffic forwarding rules on the node.
• Pods: Host one or more closely related containers and form the smallest deployable Kubernetes units.

Users submit desired state to the API server. The scheduler assigns Pods, and controllers plus kubelets continually work to make the actual state match that desired state.

A Pod is the smallest deployable and schedulable unit in Kubernetes. It contains one or more containers that must run together on the same node.

Containers within a Pod share:

• Network namespace: They use the same IP address and can communicate through localhost.
• Port space: Containers must coordinate the ports they use.
• Storage volumes: Declared volumes can be mounted by multiple containers in the Pod.
• Lifecycle and placement: The containers are scheduled and managed as one unit.

Kubernetes uses Pods because some application containers require tightly coupled helper containers. For example, a microservice container may share files or local networking with a proxy or logging sidecar.

A Pod should generally represent one application instance. Pods are also ephemeral: when a Pod fails or is replaced, a controller creates a new Pod that may receive a different IP address. Consequently, users normally manage Pods through higher-level resources such as Deployments rather than creating them directly.

A ReplicaSet maintains a specified number of identical Pod replicas. If a Pod fails or is deleted, the ReplicaSet creates a replacement. If too many replicas exist, it removes the excess.

A Deployment is a higher-level controller that manages ReplicaSets and provides controlled application updates. Its specification normally defines:

• The required number of replicas
• A label selector
• A Pod template
• The container image and ports
• Resource settings and health checks
• An update strategy

They support declarative deployment because the administrator states the desired state in a manifest rather than listing imperative steps. Kubernetes controllers compare that declaration with the actual cluster state and reconcile any difference.

During an image update, the Deployment creates a new ReplicaSet and gradually shifts replicas from the old version to the new one. It records rollout history and can roll back to an earlier ReplicaSet if the release fails. Applications should normally create Deployments and allow them to manage ReplicaSets automatically.

A Kubernetes Service provides a stable network endpoint for a changing set of Pods. It selects Pods using labels and routes traffic to healthy endpoints, allowing Pods to be replaced without requiring clients to track their individual IP addresses.

• ClusterIP: Exposes the Service on an internal cluster IP. It is the default type and is appropriate for communication between internal microservices.
• NodePort: Opens a selected port on every worker node and forwards traffic to the Service. External clients can connect using a node address and that port, although it is not usually the preferred production entry mechanism.
• LoadBalancer: Requests an external load balancer from the infrastructure provider. It supplies an externally reachable address and forwards traffic to the Service.

A Service separates service discovery from Pod lifecycle. Internal clients can use the Service's DNS name, while the backing Pods can be scaled, restarted, or replaced without changing the client configuration.

ConfigMaps and Secrets decouple configuration from container images so the same image can be deployed in multiple environments.

ConfigMaps:

• Store non-sensitive configuration such as feature settings, service URLs, and log levels.
• Can be exposed as environment variables, command-line arguments, or mounted files.

Secrets:

• Store sensitive values such as passwords, API tokens, and certificates.
• Can also be exposed through environment variables or mounted volumes.
• Require appropriate encryption, access control, and rotation policies. Base64 representation in a manifest is encoding, not encryption.

A microservice should read external configuration when it starts rather than embedding environment-specific values in its image. Access should be restricted through role-based access control, and confidential values should not be committed to source control or printed in logs. In production, Secrets may be integrated with an external secret-management system for stronger storage, auditing, and rotation.

Kubernetes probes determine the state of an application container:

• Liveness probe: Determines whether the application is still functioning. Repeated failure causes Kubernetes to restart the container.
• Readiness probe: Determines whether the application is currently able to receive traffic. Failure removes the Pod from matching Service endpoints without necessarily restarting it.
• Startup probe: Determines whether a slow-starting application has completed initialization. While it is active, liveness and readiness checks do not interfere with startup.

Incorrect configuration can cause:

• Restart loops: An aggressive liveness probe may repeatedly terminate a healthy but slow service.
• Traffic sent too early: A missing or weak readiness probe may direct requests to an instance before dependencies or caches are ready.
• Delayed failure detection: Long intervals and thresholds may leave an unhealthy instance active for too long.
• False success: A shallow probe may return success even when the service cannot perform its essential work.
• Cascading load: Probes that depend on every downstream service may remove all instances during a dependency outage.

Probe paths, delays, timeouts, periods, and thresholds should reflect the actual behavior of the microservice.

A typical deployment process contains the following stages:

1. Package the application: Create a Dockerfile and build the container image.
2. Test the image: Run automated tests and verify that the service starts correctly in a container.
3. Tag and publish: Assign an immutable version tag and push the image to an accessible registry.
4. Define configuration: Create ConfigMaps and Secrets for environment-specific settings.
5. Create a Deployment manifest: Specify the image, replica count, labels, ports, resource requests and limits, probes, and update strategy.
6. Create a Service manifest: Select the Deployment's Pod labels and expose the required application port.
7. Apply the manifests: Use kubectl apply -f <manifest> or an automated delivery system.
8. Observe the rollout: Use kubectl rollout status deployment/<name> and inspect Pods, events, and logs.
9. Validate behavior: Test the Service endpoint and monitor errors, latency, saturation, and application health.
10. Rollback if necessary: Use kubectl rollout undo deployment/<name> or redeploy a known-good image.

For reliable operation, manifests should be version-controlled, image tags should be immutable, and deployments should use health probes and appropriate resource settings.

The strategies differ in risk, resource use, and traffic control:

• Rolling update: Gradually replaces old Pods with new Pods. It usually avoids downtime and uses moderate extra capacity, but both versions may temporarily run together.
• Recreate: Terminates all old instances before starting the new version. It is simple but normally causes downtime and is useful when old and new versions cannot run simultaneously.
• Blue-green deployment: Maintains two complete environments. Traffic is switched from the current environment to the new one after validation. Rollback is fast, but infrastructure cost is higher.
• Canary deployment: Sends a small portion of traffic to the new version before gradually increasing exposure. It limits the impact of defects but requires traffic control, monitoring, and clear success criteria.

A backward-compatible, stateless service commonly uses rolling updates. Blue-green deployment is suitable when rapid traffic switching and rollback are important. Canary deployment is useful for high-risk changes that should be validated against real traffic. Database changes must remain compatible during any period in which multiple application versions coexist.

Kubernetes provides self-healing through continuous reconciliation:

• A Deployment and its ReplicaSet replace failed or deleted Pods.
• The kubelet restarts failed containers according to their restart policy.
• Pods can be rescheduled when a worker node becomes unavailable.
• Readiness probes prevent unhealthy instances from receiving Service traffic.
• Liveness probes restart containers that remain unresponsive.

Kubernetes provides scaling in several ways:

• Manual scaling: An administrator changes the replica count of a Deployment.
• Horizontal Pod Autoscaler: Adjusts the number of Pod replicas using metrics such as CPU, memory, or application-specific demand.
• Vertical Pod Autoscaler: Recommends or adjusts resource requests for Pods, depending on its configured mode.
• Cluster Autoscaler: Adds or removes worker nodes when Pods cannot be scheduled or capacity is underused.

Effective scaling requires valid resource requests, useful metrics, realistic scaling thresholds, and an application design that supports multiple instances. Stateless services are generally easier to scale horizontally than stateful services.

Continuous Integration (CI) is a development practice in which developers integrate small code changes into a shared repository frequently, and every integration is validated by an automated pipeline.

Core CI principles include:

• Frequent integration: Small changes reduce merge complexity and make failures easier to diagnose.
• Version control: Source code, tests, build files, and deployment definitions are maintained in a shared repository.
• Automated builds: Every accepted change should produce a repeatable build.
• Automated testing: Unit, integration, contract, security, and other relevant tests provide rapid feedback.
• Fast failure reporting: Developers should learn quickly when a change breaks the build.
• Consistent environments: Containers and reproducible dependencies reduce environmental differences.
• Artifact immutability: A tested artifact should be promoted between environments rather than rebuilt differently for each one.
• Build visibility: Pipeline status and failure details should be available to the team.

For microservices, each service may have an independent CI pipeline, but shared contracts and cross-service compatibility must also be tested.

A suitable CI pipeline can contain the following stages:

1. Checkout and validation: Retrieve a specific commit, validate configuration, and check formatting.
2. Dependency installation: Restore dependencies from trusted, version-controlled manifests and use caching carefully.
3. Static analysis: Run linters, type checks, and code-quality checks.
4. Unit testing: Execute fast tests and publish test and coverage reports.
5. Integration and contract testing: Verify database, messaging, API, and consumer-provider behavior where applicable.
6. Container image build: Build the image from a reviewed Dockerfile and tag it with an immutable identifier such as the commit hash.
7. Security checks: Scan dependencies, source code, secrets, and the resulting image for known vulnerabilities and policy violations.
8. Container testing: Start the built image and run smoke tests against the packaged application.
9. Registry publication: Push the tested image to an authenticated registry and record its digest.
10. Manifest validation: Validate Kubernetes YAML and policy compliance before handing the artifact to the deployment process.

The pipeline should fail immediately on required quality gates. Credentials must come from protected secret storage, and the exact tested image digest should be used during deployment so that production receives the artifact that passed CI.

The three practices represent related but distinct levels of automation:

• Continuous Integration: Developers merge changes frequently, and automated builds and tests validate each integration. Its primary goal is to keep the shared codebase in a working state.
• Continuous Delivery: Every successful change is packaged and kept ready for release. Deployment to production usually requires a deliberate approval or business decision.
• Continuous Deployment: Every change that passes all automated checks is released to production automatically, without a manual approval step.

In a microservice environment, a service's CI pipeline builds and verifies a versioned container image. Continuous Delivery can promote that image through test and staging environments and leave it ready for production approval. Continuous Deployment extends the workflow by automatically releasing the validated image to production.

Independent pipelines allow teams to release services at different rates. However, API compatibility, database migration safety, observability, security gates, and rollback mechanisms are necessary to prevent one independently released service from breaking the wider system.