Orchestration

Orchestration is the automated arrangement, coordination, and management of computer systems, middleware, and services.

Module

Orchestration is the automated arrangement, coordination, and management of computer systems, middleware, and services.

Overview

At the end of this module, you will :

  • Learn what a Kubernetes cluster is

  • Learn how to manage it in command line

  • Learn how to manage basic resources on a Kubernetes cluster

Prerequisites

Create these directories data/votingapp and data/orchestration in your home folder to manage the YAML file needed in this module.

mkdir -p ~/data/votingapp ~/data/orchestration

Command Line

The Kubernetes command-line tool, kubectl, is used to deploy and manage applications on Kubernetes. Using kubectl, you can inspect cluster resources, create, delete, and update components, look at your new cluster and bring up apps.

You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.17 client should work with v1.16, v1.17, and v1.18 master. Using the latest version of kubectl helps avoid unforeseen issues.

Installation

There are a few methods to install kubectl, here are the basics depending on the operating system :

sudo apt-get update && sudo apt-get install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl

For further information about Kubectl installation method, please refer to the Kubernetes documentation.

Configuration

In order for kubectl to find and access a Kubernetes cluster, it needs a kubeconfig file, which is created automatically when you create a cluster or successfully deploy a Minikube cluster. By default, kubectl configuration is located at ~/.kube/config.

Usage

Generally the command line format can be divide in three parts :

  1. The kubectl command line binary

  2. The action

  3. The object to manage

This can be represented like this :

kubectl <ACTION> <OBJECT>

Operations

Here is an exhaustive list of actions that can be done :

Resource types

Here is an exhaustive list of Kubernetes objects that can be managed :

Exercise n°1

Get the cluster information in command line.

kubectl cluster-info

Exercise n°2

Get the config deployed in the Kubernetes cluster.

kubectl config view

Exercise n°3

Get each elements deployed in the cluster in command line.

kubectl get all --all-namespaces
kubectl get all -A

Exercise n°4

Describe the fields associated with each supported API resource.

kubectl api-resources

YAML file

YAML, which stands for Yet Another Markup Language, or YAML Ain’t Markup Language is a human-readable text-based format for specifying configuration-type information.

Using YAML for Kubernetes definitions gives a number of advantages, including:

  • Convenience: Declaring all the parameters in a command line is no longer needed

  • Maintenance: YAML files can be added to source control to track changes

  • Flexibility: Easier to configure complex structure in a file than a command line

YAML is a superset of JSON, which means that any valid JSON file is also a valid YAML file.

The usual basic structure of a Kubernetes YAML file definition look like this :

apiVersion: [...]
kind: [...]
metadata:
    - [...]
spec:
    - [...]

  • apiVersion : API version of the object to declare

  • kind : Kubernetes object to manage (ex: Pod, Deployment, Service ...)

  • metadata : metadata of the object declared (like labels, annotations ...)

  • spec : main part of a YAML file, specification of each parameter defining the object declared (ex: image, replicas, volumes, secrets, environment ...)

Exercise n°1

Extract the default namespace YAML file definition with the command line.

kubectl get namespace default -o yaml

Exercise n°2

Extract only the useful information from the default namespace it in a YAML file.

kubectl get namespace default -o yaml > export.yaml

Architecture

Master components provide the cluster’s control plane. Master components make global decisions about the cluster (for example, scheduling), and detecting and responding to cluster events (starting up a new pod when a replication controller’s ‘replicas’ field is unsatisfied).

Master components can be run on any machine in the cluster. However, for simplicity, set up scripts typically start all master components on the same machine, and do not run user containers on this machine.

Node components are worker machine in Kubernetes, previously known as a minion. They maintain running pods and provide the Kubernetes runtime environment. They are the resources pool that will be managed by the masters to schedule the requested objects.

A basic Kubernetes architecture can be schematized like this :

Exercise n°1

List the all nodes of the cluster and identify the roles of each one.

kubectl get nodes

Exercise n°2

Describe one of the master node.

kubectl describe node HOSTNAME

Exercise n°3

Get more information about nodes in one command line.

kubectl get nodes -o wide

Namespace

Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.

Namespaces provide a scope for names. Names of resources need to be unique within a namespace, but not across namespaces.

Namespaces are a way to divide cluster resources between multiple users via the definition of resource quotas.

Exercise n°1

List all the default namespaces created by the installer.

kubectl get namespace

Exercise n°2

Create the namespace app-demo with the command line.

kubectl create namespace app-demo

Exercise n°3

Create a namespace another-demo in declarative mode with a YAML file.

apiVersion: v1
kind: Namespace
metadata:
  name: another-demo
kubectl apply  -f data/orchestration/namespace.yaml

Exercise n°4

Describe the namespace app-demo.

kubectl describe namespace app-demo

Exercise n°5

Delete the namespace named "another-demo".

Be careful on the deletion of an object in Kubernetes, there is no rollback.

Be careful on namespace deletion, each objects deployed within it will be deleted too.

# In command line
kubectl delete namespace app-demo

# With declarative file
kubectl delete -f ~/data/orchestration/namespace.yaml

Labels

Labels are key/value pairs that are attached to objects, such as pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects. Labels can be attached to objects at creation time and subsequently added and modified at any time. Each object can have a set of key/value labels defined. Each Key must be unique for a given object.

Exercise n°1

List all nodes of the cluster and display all their labels.

kubectl get nodes --show-labels

Exercise n°2

Add the key/value pair : random-key=random-value to the first node of the cluster.

kubectl label nodes HOSTNAME random-key=random-value

Exercise n°3

Delete the key/value pair : random-key=random-value of the first node of the cluster.

kubectl label nodes HOSTNAME random-key-

Module exercise

The purpose of this section is to manage each steps of the lifecycle of an application to better understand each concepts of the Kubernetes course.

The main objective in this module is to create a namespace for a future application to isolate it and label the nodes to manage the deployment of each part of the application in the next modules.

For more information about the application used all along the course, please refer to the Exercise App > Voting App link in the left panel.

Based on the principles explain in this module, try by your own to handle this steps. Each steps has to be done in command line thanks to Kubectl.

  1. Create a namespace called voting-app

  2. Update one node with the key/value label : type=database

  3. Update another node with the key/value label : type=queue

  4. Ensure each nodes are correctly configured

On single node cluster like Minikube, the key defined must be unique.

External documentations

Those documentations can help you to go further in this topic :

PreviousOverviewNextPods

Last updated