Kubernetes Resources

In this article you will learn everything about Kubernetes resources.

Deployments

A deployment in Kubernetes is a resource that manages a set of identical pods, ensuring they run the desired number of replicas, enabling updates, rollbacks, and scaling.

Example: Deploying a web application with three replicas and automatically rolling out updates when the container image is updated.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web-app
        image: web-app:1.0
        ports:
        - containerPort: 80

Pods

A pod in Kubernetes represents the smallest and simplest Kubernetes object, it is a single instance of a running application.
Example: Running a single web server in a pod.

apiVersion: v1
kind: Pod
metadata:
  name: my-web-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Containers

A container is a software and its dependencies wrapped in a virtual environment, which can be executed. Containers are managed within a pod in Kubernetes, see parts of the example above:
Example: This is the newest nginx image, which gets executed within a pod.

  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Resource requests and limits

Resource requests and limits define the minimum and maximum amounts of CPU and memory that a container can consume. Resource limits help prevent nodes from becoming overloaded, while resource requests ensure that a container is only scheduled on a node with sufficient resources.

ReplicaSets

ReplicaSets ensures a specified number of pod replicas are running at all times.

Example: Creating a ReplicaSet that runs 5 replicas of a web app.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: webapp-replicaset
spec:
  replicas: 5
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web-app
        image: web-app:1.0

Horizonal Pod Autoscaling

Horizontal Pod Autoscaling allows pods to scale based on resource utilization, such as CPU or memory usage.

Example: Configuring autoscaling for a web application based on CPU usage.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapp-hpa
spec:
  maxReplicas: 10
  metrics:
  - resource:
      name: cpu
      target:
        averageUtilization: 50
        type: Utilization
    type: Resource
  minReplicas: 2
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app-deployment

Persistent Volume

A Persistent Volume is a storage resource provisioned by an administrator that can be used by pods to persist data. In most cases, the volume is automatically provisioned by a CSI driver, eliminating the need for manual volume creation.

Example: Defining a PV that can be claimed by a pod.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-storage
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

PersistentVolumeClaim

A PersistentVolumeClaim is a request for storage that binds to a PersistentVolume. It is primarily used for dynamically provisioning storage volumes.

Example: Requesting a 50GB volume for a database pod.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-pv-claim
spec:
  storageClassName: xelon-persistent-storage
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

StorageClass

StorageClasses define different types of storage that can be dynamically provisioned.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: xelon-persistent-storage
provisioner: csi.xelon.ch
reclaimPolicy: Delete
volumeBindingMode: Immediate

Networking

This section covers the essential communication between Kubernetes components, including pods, services, and external entities.

Services

There are several types of services, each with its own characteristics. However, all service types share common features, including a stable IP address and DNS name for a selected set of Pods.

ClusterIP

The ClusterIP is the most common and default service type. It exposes a service internally within the cluster, providing an IP address that is accessible only from inside the cluster.

apiVersion: v1
kind: Service
metadata:
  name: web-app-svc-ci
spec:
  selector:
    app: web-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

NodePort

The NodePort exposes your service on each node at a port above 30000. It is useful if you want to expose services directly on your node network. This service type is commonly used when a firewall with load-balancing capabilities is in front of your cluster.

apiVersion: v1
kind: Service
metadata:
  name: web-app-svc-np
spec:
  selector:
    app: web-app
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: NodePort

LoadBalancer

The LoadBalancer service type is an "automated" NodePort. When you create a service of this type, it automatically requests a NodePort and sets up forwarding rules on the load balancer. These requests are handled by the Cloud-controller-manager component. It is commonly used to expose services to the World Wide Web.

apiVersion: v1
kind: Service
metadata:
  name: web-app-svc-lb
spec:
  selector:
    app: web-app
  ports:
    - port: 8000
      targetPort: 80
      protocol: TCP
  type: LoadBalancer

L7 Service Control

Layer 7 Service Control allows the management of traffic routing at the application layer, enabling features like URL-based routing.

Ingress Controller

The Ingress Controller is a legacy approach (though still widely used) for handling traffic routing to your application. The Ingress Controller itself is a web server that is dynamically configured using the Ingress resource.

Example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
spec:
  ingressClassName: cilium
  rules:
  - host: fqdn.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-app-svc-ci
            port:
              number: 80
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: web-app-backend-svc-ci
            port:
              number: 80

GatewayAPI

The GatewayAPI is the successor to the Ingress resource. It provides a more standardized approach for managing features like TLS, gRPC, and special functions, which were previously handled through annotations. Ultimately, both solutions create a configuration file for a reverse proxy.

Example Gateway:

apiVersion: networking.k8s.io/v1alpha1
kind: Gateway
metadata:
  name: webapp-gateway
spec:
  gatewayClassName: cilium
  listeners:
  - protocol: HTTP
    port: 80
    routes:
      kind: HTTPRoute
      namespaces:
        from: Selector
        selector:
          matchLabels:
            app: web-app

 apiVersion: networking.k8s.io/v1alpha1
kind: HTTPRoute
metadata:
  name: webapp-route
spec:
  parentRefs:
  - name: webapp-gateway
  rules:
  - matches:
    - path:
        type: Prefix
        value: /
    forwardTo:
    - serviceName: web-app-svc-ci
      port: 80
  - matches:
    - path:
        type: Prefix
        value: /api
    forwardTo:
    - serviceName: web-app-backend-svc-ci
      port: 80

mysql -h <servicename> -u admin -p
# Exmaple with dns records
mysql -h database -u admin -p

 mysql -h <servicename>.<namespace> -u admin -p
# Exmaple with dns records
mysql -h database.prod -u admin -p

mysql mysql -h <servicename>.<namespace>.svc.<cluster-domain> -u admin -p
# Exmaple with dns records
mysql -h database.prod.svc.cluster.local -u admin -p