Autor: oveits

Kubernetes Services provide us with a means to load-balance between many instances of an application running on a data center. Moreover, they help make accessible the service from the Internet. Here, we will show, how PODs, endpoints, container-ports, and node ports are bound together by means of Kubwernetes Services.

In this blog post, we have created a Kubernetes DaemonSet. We have observed that and POD template changes are not propagated to existing PODs if we choose the OnDelete update strategy. However, if we choose the RollingUpdate strategy, POD renewal is triggered with any update of the DaemonSet's POD template.

In this blog post, we will have a closer look to Deployments, how they relate to ReplicaSets of the last post, and which features in terms of the rollout/rollback they offer to the Kubernetes administrator.

In this lab, we will have a closer look at Kubernetes Replicasets. First, we will learn how ReplicaSets control, how many POD replicas are up and running at any time. We will learn, how ReplicaSets and PODs are connected: via labels. We will show that manually creating PODs with matching labels can have weird cuckoo's eggs effects. Moreover, a POD can be detached from a ReplicaSet without stopping it by manipulating its label.

In this Kubernetes lab, we will explore Kubernetes Jobs and CronJobs. Unlike Kubernetes Deployments, Kubernetes Jobs are designed to quit after they have accomplished the task (successful or not). Kubernetes CronJobs are the jobs that are repeated according to a schedule pattern Linux administrators know from crontab.

In this lab, we will explore the Kubernetes API. We will read and create PODs before we explore the API resources.

In this LSF458 lab (originally Excercise 4.3 and 4.4), we will explore how to manage maintenance modes of nodes in a Kubernetes cluster. For that, we will deploy a complex example, before we drain the node. Step 0: Enter Kubernetes…

This lab is concentrating on Kubernetes Resource Management. We will explore Limit Ranges applied to each container as well as Resource Quotas that limit the allowed sum resources of a namespace.

In part 3 of the Certified Kubernetes Administrator Labs Challenge, we will deploy a simple application by file and by command. Then we will expose and access the service from within the Kubernetes Cluster. After that, we will explore how Kubernetes Deployments helps us maintain the service by automatically restarting failed PODS through ReplicaSets. Last, but not least, we will discuss how to access the service from outside the Kubernetes cluster.

For the Certified Kubernetes Administrator Labs Challenge, I have decided to use the  Katakoda Kubernetes Playground. This way, I do not need to install any Kubernetes cluster before starting the labs. This will be tested now.

The Challenge: perform all eleven labs of LSF558 as a path towards the Certified Kubernetes Administrator (CKA) exam within a day.

In our most recent blog post, we have shown how to install ElasticSearch via Helm. This time, we will add a Kibana server (via Helm again), so we can visualize the data stored in the ElasticSearch database. Compared to the…

There may be simpler possibilities for installing ElasticSearch on Docker. However, here, we will choose a way that can be easily expanded for production use: the installation of ElasticSearch on Kubernetes via Helm charts. While installing ElasticSearch using Helm implements…