YAML Configuration

Overview of Kubernetes Configuration Files

• Purpose: Primary tool for creating and configuring Kubernetes components.

• Structure: YAML format, straightforward but indentation-sensitive.

---

Key Sections in Configuration Files

1. Metadata

• Contains identifying information for the component

  • Example: name of the component.

  • Includes labels which are key-value pairs used for selection and grouping.

    • Example: app: nginx

2. Specification (spec)

• Defines the desired state and configuration of the component.

• Attributes vary depending on the component type.

  • For Deployments:

    • replicas: Number of pod instances to maintain.

    • template: Blueprint for creating pods.

      • Contains its own metadata and spec.

      • Specifies:

        • containers list

          • Image to use

          • Container name

          • Ports exposed

  • For Services:

    • selector: Matches service to the correct pods using labels.

    • ports: Includes:

      • port: Port exposed by the service.

      • targetPort: Port on the container that receives traffic.

3. Status

• Generated and maintained automatically by Kubernetes.

• Purpose: Reflects the current state of a component.

  • Compared with the spec (desired state) to detect discrepancies.

  • Supports self-healing: If actual state deviates from desired, Kubernetes initiates corrective action.

• Status source: Extracted from etcd — the Kubernetes cluster's data store.

  • Contains real-time status of all components.

• Example:

  • Specified: 2 replicas.

  • If only 1 replica is running, Kubernetes creates another automatically.

---

Deployment and Pod Relationship

• Deployments manage Pods.

  • Changes to a Deployment cascade to its Pods.

  • To create Pods, define a Deployment which handles pod creation and lifecycle.

Pod Template within Deployment Spec

• Acts as a "configuration file inside a configuration file."

• Contains:

  • Metadata (e.g., labels)

  • Spec:

    • Container image

    • Exposed ports

    • Resource definitions (if applicable)

---

Connecting Components with Labels and Selectors

Labels

• Located in metadata.

• Key-value pairs assigned to components.

  • Example: app: nginx

Selectors

• Located in spec of Services and Deployments.

• Match labels to bind components together.

• Example:

  • Pods labeled app: nginx

  • Service selector app: nginx

  • Ensures Service routes traffic to the correct Pods.

---

Service-Port Configuration

• Services expose and route traffic to Pods via ports.

Port Definitions:

• port: External port exposed by the Service.

• targetPort: Internal port on the container receiving the traffic.

  • Must match the container's port definition.

Example:

• Service nginx-service:

  • port: 80

  • targetPort: 80

  • Ensures that traffic arriving at port 80 is routed to containers also listening on port 80.

---

Storage and Management of Configuration Files

• Common Practices:

  • Store with application source code.

  • Enables versioning and aligns with Infrastructure-as-Code (IaC) principles.

  • Alternatively, use a dedicated Git repository for configs.

---

YAML Format Specifics

• YAML is indentation-sensitive.

• Validation Tip:

  • Use online YAML validators, especially for large files (~200+ lines).

---

Applying Configuration Files

• Command: kubectl apply -f <filename>

  • Applies the configuration and creates/updates components.

Verification

• Use kubectl get pods to verify deployment state.

  • Example: 2 replicas shown as Running.

• Use kubectl get services to verify service creation and ports.

Inspecting Service-Pod Binding

• Command: kubectl describe service <service-name>

  • Shows:

    • selector

    • targetPort

    • endpoints (IP addresses of connected pods)

• To get Pod IPs:

  • Command: kubectl get pods -o wide

  • Outputs:

    • Pod name

    • Status

    • IP address (used to verify against service endpoints)

---

Inspecting the Generated Status

• Command: kubectl get deployment <name> -o yaml

• View full configuration including status and auto-added fields.

• Optionally, redirect output to file for comparison or debugging.

  • Example:

    • Save to: nginx-deployment-result.yaml

    • Open alongside original file for comparison.

Added by Kubernetes:

• status:

  • Running replicas

  • Replica states

• metadata:

  • creationTimestamp

  • uid

• spec:

  • Default values for unspecified attributes

Use in Debugging:

• Compare the desired state (spec) with the actual state (status) to identify issues.