SKS ADVANCED

Building up on your existing K8s knowledge, we dive deeper into Kubernetes concepts, related storage technologies, applications and troubleshooting.

SKS Welcome

Welcome

In this SKS Advanced training, we shift gears and dig into the more advanced Kubernetes (K8s) areas: storage, routing, and debugging. Again, we will take a practical approach to these advanced K8s topics and show you more of the technology’s magic.

VIDEO

Welcome

Kubernetes Concepts

In this section, we cover various concepts and explain how to leverage the declarative orchestration powers of Kubernetes. We show different usage scenarios of initial configurations and necessary update operations in an SKS Cluster that provides a convenient managed Kubernetes Service to run containerized workloads at scale.

Ingress
Cluster
Manifests
Namespaces
Updates

Ingress

We already know the LoadBalancer service in Kubernetes from the SKS starter course. However, LoadBalancer works only on network layer 4; it can not distinguish between different hostnames and paths and cannot terminate SSL traffic. These additional capabilities are provided in Kubernetes by the Ingress service.

The Ingress uses a reverse proxy, like Nginx, to handle network layer 7 balancing in the Kubernetes cluster and the often needed additional, multiple routing paths. If there are advanced routing demands, the Ingress service can provide and handle them.

VIDEO

Ingress

Ingress Config

How to configure an Ingress? The Ingress service consists of two parts, first, the Ingress Controller and second, the Ingress Configuration (called Ingress in Kubernetes). Kubernetes is reading the configuration and deploying it to the controller.

The video below shows the flow of the configuration process.

VIDEO

Ingress Config

Cluster Structure

Let’s have a look at the Kubernetes Cluster and its components. Although it is quite a complex structure, the beauty of SKS is that we manage the complexity. Kubernetes as a managed service remains a very flexible solution because the possibility of shaping the services with add-ons makes it very customizable.

VIDEO

Cluster Structure

Manifest Theory

The beauty of Kubernetes lies in its descriptive/declarative nature of infrastructure management and operation. Instead of writing a series of single commands on the CLI, you write it down in a stateless manifest; the format used is a .yaml - file.

The manifest concept details and how to compose them are laid out in the video below.

VIDEO

Manifest Theory

Manifest Praxis

Let’s look at the actual usage of the manifest concept and how to apply it to a Kubernetes cluster and create, configure, and re-configure resources with it.

The manifest usage details and how to execute them are laid out in the video below.

VIDEO

Manifest Praxis

Manifest Tricks

Building a manifest from scratch can be tedious. However, you can use many cool tricks to develop your manifests, like automatically creating a manifest with the kubectl command and the --dry-run option or using a pre-build manifest from the Kubernetes documentation to start with.

VIDEO

Manifest Tricks

Namespace Theory

Namespaces provide separation of components and are a construct to introduce additional structure to your configurations.

How the construct namespace works is shown in the video below.

VIDEO

Namespace Theory

Namespace Praxis

How does this separation look like in praxis, and how to leverage the namespace concept for better orchestration.

See the application of this construct in praxis in the video below.

VIDEO

Namespace Praxis

Updates Theory

The manifest concept is very versatile for creating and orchestrating Kubernetes structures but also updating. Declaring the new situation and triggering the update, Kubernetes takes care of the rest, which means following a clearly defined workflow of process steps to update all distributed components and safely removing old versions.

The details are explained in the video below.

VIDEO

Updates Theory

Updates Praxis

The kubectl command provides rollout and update capabilities for containerized applications and the associated Kubernetes constructs. Users expect applications to be available all the time, and developers deploy new versions of them several times a day.

The concept of rolling updates allows an update with zero downtime by incrementally updating Pods with new ones. With the command > kubectl rollout ..., you then can check the status of your deployment. You can also undo your deployment in an unsuccessful rollout and set it back to an older version.

The declarative nature of Kubernetes and the tracking of your actions makes undo’s and redo’s possible to keep the desired state of your application while extending or fixing the very same application. And, if necessary, make changes to the actual condition in a controlled way to reach the desired state again. Suppose done right with zero downtime for your application.

The video below demonstrates this rather complex sounding process in some of its possible variations. Therefore, a more extended sequence was necessary to show all the essential concepts coming together and let you experience the flexibility and stability of a Kubernetes environment.

VIDEO

Updates Praxis

Kubernetes Storage

In this section, we cover various aspects of storage in the context of Kubernetes. We show different usage scenarios of temporary and persistent storage supplied with respective volume versions and other storage technologies and the configurations of these variants.

Volumes
Persistent Volumes
Storage Technologies
Exoscale Block Storage

Volumes

Containerized (stateless) applications have the same needs as normal (stateless) applications. They need all types of storage to share, read, and access information. Attaching and sharing temporary storage to a Pod, respective to a container or multiple containers, is handled by the volume concept.

Different storage types can be mounted and used by containers, e.g., temporary volumes, network volumes, and configuration maps. The video below shows how volumes are defined and used in manifests, the configuration mechanism in Kubernetes.

VIDEO

Volumes

Persistent Volumes

Overview

Kubernetes, a powerful container orchestration platform, abstracts and simplifies the management of containerized applications. One crucial aspect of running applications is data persistence, where Persistent Volumes (PVs) come into play. PVs provide a robust way to manage storage that outlasts the lifecycle of individual pods. Kubernetes is usually meant to be stateless. If you need to run Databases, one recommended way is to use Exoscale’s Managed Database service (DBaaS).

If you want to run stateful workloads in Kubernetes itself, temporary storage managed by volumes is not suitable for this application category. You should use a StatefulSet and then for example Exoscale’s Block Storage.

A Persistent Volume (PV) in Kubernetes is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using storage classes. PVs are independent of the lifecycle of a pod that uses the storage. They encapsulate implementation details about the storage, including whether it is backed by NFS, iSCSI, cloud provider storage systems, or other storage technologies.

Key Concepts

Persistent Volume (PV)

Definition: A Persistent Volume is a cluster resource, similar to a node, representing a piece of storage. It is created by an administrator or dynamically through a StorageClass.
Lifecycle Independence: PVs exist independently of the pods. They persist even when the pods using them are deleted, thereby retaining data across pod restarts and rescheduling.

Persistent Volume Claim (PVC)

Definition: A Persistent Volume Claim is a user’s request for storage. It binds to an available PV that meets the claim’s resource requirements.
Coupling with PV: When a PVC is created, Kubernetes looks for a suitable PV or dynamically provisions one based on the StorageClass defined. Once a PV is bound to a PVC, it remains bound until the PVC is deleted.

StorageClass

Definition: A StorageClass describes the different types of storage offered by the cluster. It allows administrators to define classes of storage, such as fast or slow, which PVCs can then reference for dynamic provisioning.
Dynamic Provisioning: StorageClasses enable dynamic provisioning of Persistent Volumes, meaning PVs can be created on-demand when a PVC is made without pre-provisioning them.

Access Modes

PVs have access modes that describe how they can be mounted to a host:

ReadWriteOnce (RWO): A single node can mount the volume as read-write.
ReadOnlyMany (ROX): Many nodes can mount the volume as read-only.
ReadWriteMany (RWX): Multiple nodes can mount the volume as read-write.

These access modes help define how the storage can be consumed, facilitating different use cases and performance characteristics.

Lifecycle of a Persistent Volume

Provisioning

Static Provisioning: An administrator manually creates PVs specifying the storage details.
Dynamic Provisioning: When a PVC is created, Kubernetes uses a StorageClass to provision a PV to fulfill the claim automatically.

Binding

Kubernetes attempts to find an available PV that matches the PVC’s specified resources and access modes. If found, it binds the PV to the PVC.

Using

Once a PV is bound to a PVC, pods can mount and use the storage by referencing the PVC.

Reclaiming

When a PVC is deleted, the PV enters a reclaim phase determined by its reclaim policy (Retain, Recycle, Delete):

Retain: The PV remains in the cluster, retaining its data. It needs to be manually cleaned up and reused.
Recycle: The PV’s data is scrubbed and becomes available again. (Deprecated in newer versions)
Delete: The PV and its associated storage are deleted.

Benefits of Persistent Volumes

Data Persistence: Provide a way to persist data beyond the lifecycle of individual pods, enabling stateful applications.
Decoupling of Storage and Compute: Independently manage storage and compute resources, allowing for flexible scaling and management.
Centralized Storage Management: Simplifies the storage administration by abstracting the underlying storage infrastructure.

Use Cases

Databases: Where data persistence, performance, and integrity are crucial.
Content Management Systems (CMS): Where multiple instances need access to shared data.
File Storage: For applications requiring shared access to multiple node files.

In summary, Persistent Volumes in Kubernetes are essential for managing persistent storage in a container orchestration environment. They provide a scalable and flexible solution for stateful applications that need to maintain data across the lifecycle of pods.

Persistent Volume Access Modes

Persistent Volumes (PVs) in Kubernetes provide a reliable and consistent way to store data essential for applications running in a cluster. They support various access modes that determine how nodes can mount and access the volume. This allows administrators to choose the proper storage solution based on their application’s requirements.

Here, we describe two common access modes:

ReadWriteOnce
ReadWriteMany

ReadWriteOnce (RWO)

The ReadWriteOnce access mode allows a single node to mount the volume as read-write. Only one pod running on one node can write to the volume at a time.

Advantages

Performance: This mode offers the best performance since no file-locking requirements exist. The absence of locking mechanisms reduces latency and overhead, making data operations faster and more efficient.
Simplicity: Ideal for applications that don’t need concurrent write access from multiple nodes, simplifying data consistency management

Use Cases

Databases: Suited for database workloads where data consistency and integrity are critical.
Stateful Applications: Applications where each instance manages its data independently.
Storage Types: Commonly supported by block storage solutions, which are optimized for high performance and low-latency access.

ReadWriteMany (RWX)

The ReadWriteMany access mode allows the volume to be simultaneously mounted as read-write by multiple nodes. This enables several pods across different nodes to access and modify the data concurrently.

Advantages

Shared Workloads: This feature enables scenarios where multiple instances of an application need to write to a common data set, facilitating easy sharing and collaboration.
Scalability: Enhances scalability for applications that can benefit from distributed read-write access.

Considerations

File Locking: This requires file-locking mechanisms to ensure data consistency and integrity when multiple nodes are writing to the volume simultaneously. This can introduce latency and negatively affect performance.
Complexity: The need for file-locking can complicate application logic and database management, making it unsuitable for high-performance, heavily transactional applications.

Use Cases

Content Management Systems (CMS): Ideal for web applications where content can be modified by multiple users or instances simultaneously.
Shared File Repositories: Useful for applications that need a shared filesystem accessible from multiple pods.
Storage Types: This mode often requires distributed file systems or network-based storage solutions, such as NFS (Network File System) or GlusterFS, that can handle concurrent access from multiple clients.

Understanding these access modes helps you choose the proper storage backend and optimize the performance based on the specific needs of your applications in a Kubernetes environment.

VIDEO

Persistent Volumes

Storage

COMPONENT ==========

{: type=“html” «««< HEAD display_name=“Overview” }

Due to its extensible nature, Kubernetes can leverage a multitude of storage technologies. Various solutions are available, especially for persistent volume scenarios. Of course, there are also open-source variants.

Block Storage is essential for providing persistent storage by directly exposing storage blocks to workloads running on Kubernetes. This technology caters to cases requiring high performance, low latency, and fine-grained control over I/O operations. Block storage can be provisioned through various cloud providers or on-premises solutions, offering flexibility and scalability for stateful applications and databases in Kubernetes environments. It enables Kubernetes to deliver reliable and durable storage that integrates seamlessly with the pods, irrespective of where they are deployed.
GlusterFS is a notable open-source project that provides a mechanism to deploy native storage services onto a Kubernetes cluster quickly. It is a precisely defined file storage framework that can scale to petabytes, utilize any on-disk file system backing different features, and handle many users. ======= display_name=“Storage” }

Applications in Kubernetes, due to its extensible nature, can leverage a multitude of storage technologies.

ed689e2 (Block storage first pass)

Local Storage Can be mounted and used for temporary (volatile) data. But not for data which needs to persist.
Object Storage Should be built into the application itself. Any compatible S3 library can be used to save static files. Alternativley, it can be mounted as PVC (for example with Mountpoint). Note that due the nature of S3, it cannot provide high IOPS.

«««< HEAD

OpenEBS is the leading open-source project that offers cloud-native storage solutions for Kubernetes deployments. Unlike any other storage option, OpenEBS can easily be integrated with Kubernetes, making it a highly-rated cloud-native storage on the CNCF landscape.
Portworx is another container storage solution intended for Kubernetes, focusing on highly available clusters. It is host-attached storage, where every volume directly maps to the host to which it is attached. These volumes are accessed through I/O technology and provide auto-tuning based on the I/O protocol used.
Rook is a top-rated open-source storage solution for Kubernetes, but it differs from others due to its storage orchestrating capacities. In addition, Rook is a production-grade solution that transforms storage volumes into self-scaling, self-healing, and self-managing storage systems to integrate with the Kubernetes environment perfectly.

Many more technologies are available. A complete, up-to-date list of supported technologies is on Kubernetes Storage.

Block Storage Can be attached to a single instance and subsequently reattached to different instances as needed. This feature makes it a natural choice for StatefulSets utilizing Kubernetes Persistent Volume Claims (PVCs).

Many more technologies are available. For example the Open-Source Software Longhorn can be used to distribute storage over multiple local storage volumes.

ed689e2 (Block storage first pass)

Exoscale Block Storage

Overview

Exoscale’s Block Storage offers a robust and distributed block device solution for Exoscale Compute instances, known for its redundancy and reliability. A Volume, a singular storage unit, can be partitioned and formatted to accommodate directories and files. One of the critical features of Block Storage is the Snapshot, which captures the state of a volume at a specific moment, allowing users to create new volumes based on that state.

Exoscale’s Block Storage provides high-performance volumes over a network, making it an optimal database choice. These volumes require integration using a Container Storage Interface (CSI) driver. Block Storage supports the ReadWriteOnce access mode, ensuring that volumes are persistent and can automatically detach and reattach to nodes when a Pod is rescheduled. Additionally, the system supports snapshots, allowing users to capture the state of a volume at any given moment and create new volumes based on that state. This feature underscores the redundancy and reliability that Exoscale’s Block Storage offers.

NOTE! Here, you can find more details on Block Storage.

Kubernetes CSI

Block Storage can be directly used in Kubernetes via Exoscale CSI-Plugin which you can select to install during SKS cluster creation. Alternativley, it can be installed using the directions in the CSI’s Github Repository.

Here is an example using a Pod:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: exoscale-block-storage
  resources:
    requests:
      storage: 10Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: nginx
    volumeMounts:
    - mountPath: "/usr/share/nginx/html"
      name: my-storage
  volumes:
  - name: my-storage
    persistentVolumeClaim:
      claimName: my-pvc

It creates a single Pod and mounts a Block Storage Volume with 10 gigabytes of storage. Should the Pod be moved to a different node, Kubernetes can also move the Block Storage Volume to the new node.

Here is an example using a StatefulSet, which is commonly used for databases. For each Pod created by the StatefulSet, a Block Storage volume is attached. If a Pod is relocated, it is matched with the same Block Storage Volume that was originally created for it.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web-server
spec:
  serviceName: "web"
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:latest
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi
      storageClassName: exoscale-block-storage

Make sure to check kubectl describe pod PODNAME -n NAMESPACENAME and kubectl get events -n NAMESPACENAME if you encounter problems.

Troubleshooting

In this section, we cover various techniques to stay ahead of the game running workloads with Kubernetes. We keep in mind the cycle of Development, Operations, Monitoring, DevOps, and Debugging in agile environments powered by modern software solutions. We are looking at necessary tasks and how to get things done with graphical and CLI tools.

k8slens.dev
kubectl

Errors, Debugging …

The art of identifying and finding errors in IT systems, if it’s code or if it’s infrastructure configurations, today they are almost the same. However, both sides of IT systems challenge us with increased complexity, the cost for more flexibility, features, and performance.

Hence, the toolbox we must have to conquer those challenges needs to be fine-honed to do the trick. The preferences in tools are vast, and we look at both diametral ends of tools sets, graphical user interface, and command line.

VIDEO

Debugging