Kubernetes Cluster

Kubernetes Cluster – Kubernetes Tutorial. Here Coding compiler sharing a tutorial on Kubernetes cluster, Kubernetes cluster overview, Kubernetes cluster configuration, and Kubernetes extensions. Let’s start learning about Kubernetes. Happy learning.

Table of Contents

Kubernetes is highly configurable and extensible. As a result, there is rarely a need to fork or submit patches to the Kubernetes project code.

This guide describes the options for customizing a Kubernetes cluster. It is aimed at Cluster Operators who want to understand how to adapt their Kubernetes cluster to the needs of their work environment.

Developers who are prospective Platform Developers or Kubernetes Project Contributors will also find it useful as an introduction to what extension points and patterns exist, and their trade-offs and limitations.

Read Related Article: What is Kubernetes?

Kubernetes Cluster Overview

Customization approaches can be broadly divided into the configuration, which only involves changing flags, local configuration files, or API resources; and extensions, which involve running additional programs or services. This document is primarily about extensions.

Related Article For You: Kubernetes Components

Kubernetes Cluster Configuration

Configuration files and flags are documented in the Reference section of the online documentation, under each binary:

kubelet
kube-apiserver
kube-controller-manager
kube-scheduler

Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with the managed installation. When they are changeable, they are usually only changeable by the cluster administrator.

Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.

Related Article: Kubernetes Objects

Kubernetes Cluster Extensions

Extensions are software components that extend and deeply integrate with Kubernetes. They adapt it to support new types and new kinds of hardware.

Most cluster administrators will use a hosted or distribution instance of Kubernetes. As a result, most Kubernetes users will need to install extensions and fewer will need to author new ones.

Related Article: Kubernetes Names And Namespaces

Kubernetes Cluster Extension Patterns

Kubernetes is designed to be automated by writing client programs. Any program that reads and/or writes to the Kubernetes API can provide useful automation. Automation can run on the cluster or off it.

By following the guidance in this doc you can write highly available and robust automation. Automation generally works with any Kubernetes cluster, including hosted clusters and managed installations.

Related Article: Kubernetes API Tutorial

There is a specific pattern for writing client programs that work well with Kubernetes called the Controller pattern. Controllers typically read an object’s .spec, possibly do things, and then update the object’s .status.

A controller is a client of Kubernetes. When Kubernetes is the client and calls out to a remote service, it is called a Webhook. The remote service is called a Webhook Backend. Like Controllers, Webhooks do add a point of failure.

In the webhook model, Kubernetes makes a network request to a remote service. In the Binary Plugin model, Kubernetes executes a binary (program). Binary plugins are used by the kubelet.

Related Article: Kubernetes Architecture Tutorial

Below is a diagram showing how the extensions points interact with the Kubernetes control plane.

Kubernetes Cluster Extension Points

This diagram shows the extension points in a Kubernetes system.

Users often interact with the Kubernetes API using kubectl. Kubectl plugins extend the kubectl binary. They only affect the individual user’s local environment, and so cannot enforce site-wide policies.
The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the API Access Extensions section.
The apiserver serves various kinds of resources. Built-in resource kinds, like pods, are defined by the Kubernetes project and can’t be changed. You can also add resources that you define, or that other projects have defined, called Custom Resources, as explained in the Custom Resources section. Custom Resources are often used with API Access Extensions.
The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the Scheduler Extensions section.
Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. Network Plugins allow for different implementations of pod networking.
The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via Storage Plugins.

If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.

Kubernetes Cluster – Kubernetes Tutorial