Search Results for: kubernetes

We use NginX-based Kubernetes Ingress Controllers to make Kubernetes Services available to the outside world. In our example, three separate applications share the same IP address and port. We show, how to retrieve the NginX configuration from the Ingress Controller. Moreover, we show how to install a newer NginX version provided by NginX INC.

How to get hands-on experience with Kubernetes affinity and anti-affinity for both, node affinity as well as POD affinity for „soft“ and „hard“ rules.

In this blog post, we will get hands-on experience on Kubernetes taints and tolerations. Taints are used to repel PODs from running on a certain set of nodes, while tolerations in the POD’s specification allows the POD to ignore the corresponding matching taint.

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.