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 :

OperationDescription

annotate

Update the annotations on a resource

api-resources

Print the supported API versions on the server, in the form of "group/version"

apply

Apply a configuration to a resource by filename or stdin

attach

Attach to a running container

auth

Inspect authorization

autoscale

Auto-scale a Deployment, ReplicaSet, or ReplicationController

certificate

Modify certificate resources

cluster-info

Display cluster info

config

Modify kubeconfig files

convert

Convert config files between different API versions

cordon

Mark node as unschedulable

cp

Copy files and directories to and from containers

create

Create a resource from a file or from stdin

delete

Delete resources by filenames, stdin, resources and names, or by resources and label selector

describe

Show details of a specific resource or group of resources

drain

Drain node in preparation for maintenance

edit

Edit a resource on the server

exec

Execute a command in a container

explain

Documentation of resources

expose

Take a replication controller, service, deployment or pod and expose it as a new Kubernetes Service

get

Display one or many resources

label

Update the labels on a resource

logs

Print the logs for a container in a pod

patch

Update field(s) of a resource using strategic merge patch

plugin

Runs a command-line plugin

port-forward

Forward one or more local ports to a pod

proxy

Run a proxy to the Kubernetes API server

replace

Replace a resource by filename or stdin

rolling-update

Perform a rolling update of the given ReplicationController (Deprecated)

rollout

Manage the rollout of a resource

run

Run a particular image on the cluster

scale

Set a new size for a Deployment, ReplicaSet, Replication Controller, or Job

set

Set specific features on objects

taint

Update the taints on one or more nodes

top

Display Resource (CPU/Memory/Storage) usage

uncordon

Mark node as schedulable

version

Print the client and server version information

Resource types

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

Resource typeAbbreviated alias

all

all

certificatesigningrequests

csr

clusterrolebindings

clusterrolebindings

clusterroles

clusterroles

componentstatuses

cs

configmaps

cm

controllerrevisions

controllerrevisions

cronjobs

cronjobs

customresourcedefinition

crd

daemonsets

ds

deployments

deploy

endpoints

ep

events

ev

horizontalpodautoscalers

hpa

ingresses

ing

jobs

jobs

limitranges

limits

namespaces

ns

networkpolicies

netpol

nodes

no

persistentvolumeclaims

pvc

persistentvolumes

pv

poddisruptionbudgets

pdb

podpreset

podpreset

pods

po

podsecuritypolicies

psp

podtemplates

podtemplates

replicasets

rs

replicationcontrollers

rc

resourcequotas

quota

rolebindings

rolebindings

roles

roles

secrets

secrets

serviceaccounts

sa

services

svc

statefulsets

sts

storageclasses

sc

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