Working with Kubernetes

In this guide, you'll learn the fundamentals of working with Kubernetes while integrating it into a CI/CD pipeline alongside Jenkins. Although this article does not cover every detail of Kubernetes, you will gain a solid understanding of core components necessary for effective cluster management.

Understanding Pods in Kubernetes

In Kubernetes, you deploy applications as pods rather than as individual containers. A pod is an abstraction layer that encapsulates one or more containers that work in unison, making it easier to manage them as a single unit. For instance, if your application requires three instances, you deploy three pods instead of dealing with three separate containers.

Below is an example YAML configuration for creating a pod:

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    name: myapp
spec:
  containers:
    - name: myapp
      image: <Image>
      resources:
        limits:
          memory: "128Mi"
          cpu: "500m"
      ports:
        - containerPort: 5000

Key aspects of the YAML file include:

• Kind: Specifies that the resource is a Pod.
• Metadata: Contains the pod name and labels (key-value pairs used to tag resources).
• Spec: Defines the configuration, including the list of containers, each with their name, image (which can be sourced from Docker Hub or private repositories), resource limits, and ports.

To deploy this pod, run the following command using the Kubernetes CLI (kubectl):

# kubectl apply -f pod.yaml

Below is an illustrative diagram explaining a Kubernetes pod setup:

Deployments in Kubernetes

While deploying pods directly is possible, Kubernetes provides an abstraction called a "deployment" to simplify the management of pod lifecycles. A deployment not only creates multiple pod replicas but also monitors them, restarts failed pods, handles scaling, and manages rollouts and rollbacks. For example, if your application needs a continuous presence of three instances, a deployment ensures that exactly three pods remain active.

Here is a typical deployment YAML configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      name: myapp
  template:
    metadata:
      labels:
        name: myapp
    spec:
      containers:
        - name: myapp
          image: <Image>
          resources:
            limits:
              memory: "128Mi"
              cpu: "500m"
          ports:
            - containerPort: 5000

This configuration highlights:

• apiVersion & Kind: Uses apps/v1 for deployments.
• Replicas: Specifies the desired number of pod instances.
• Selector & Template: The selector identifies which pods the deployment should manage and links to the pod template that defines the pod specification.

Deploy the configuration using:

# kubectl apply -f deployment.yaml

The diagram below illustrates how a deployment manages multiple pods and maintains application stability:

Managing Multiple Clusters with kubectl

Many organizations operate multiple Kubernetes clusters, such as production, staging, and development, and managing them efficiently is key. The kubectl CLI supports connecting to multiple clusters via a kubeconfig file, which stores all the relevant configuration details and credentials.

Below is a sample kubeconfig file:

apiVersion: v1
kind: Config
preferences: {}
clusters:
- name: cluster2
  cluster:
    server: https://192.168.54.19:8443
- name: cluster1
  cluster:
    server: https://192.168.59.123:8443
contexts:
- name: john@cluster1
  context:
    cluster: cluster1
    user: john
- name: mike@cluster2
  context:
    cluster: cluster2
    user: mike
current-context: cluster1
users:
- name: john
  user:
    client-certificate: <path-to-client-certificate>
    client-key: <path-to-client-key>
- name: mike
  user:
    client-certificate: <path-to-client-certificate>
    client-key: <path-to-client-key>

Explanation of the kubeconfig structure:

• Clusters: Lists each Kubernetes cluster with its API server endpoint.
• Users: Specifies credentials for accessing the clusters.
• Contexts: Ties each user to a specific cluster.
• Current Context: Determines the default context used by kubectl.

By default, kubectl searches for this configuration file in the $HOME/.kube/config directory. You can also specify the configuration location using:

To switch between contexts (and hence clusters), use the following commands:

> kubectl config use-context john@cluster1

And to switch to another context:

> kubectl config use-context mike@cluster2

Using multiple contexts is essential in a CI/CD pipeline. For instance, you might deploy to a staging cluster first (e.g., using mike@cluster2) before promoting changes to the production cluster.

The following diagram shows how kubectl connects to various Kubernetes clusters:

By understanding these core concepts—pods, deployments, and kubeconfig management—you are now well-equipped to configure and manage Kubernetes environments within your CI/CD pipelines using Jenkins. For more detailed Kubernetes information, consider exploring the Kubernetes Documentation and other helpful resources.