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.12 client should work with v1.11, v1.12, and v1.13 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 :
# Download the binary
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
# Manage the execution right to the binary
chmod +x ./kubectl
# Move the binary to the PATH
sudo mv ./kubectl /usr/local/bin/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 :
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 :
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.
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 linekubectldeletenamespaceapp-demo# With declarative filekubectldelete-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.
Add the key/value pair : random-key=random-value to the first node of the cluster.
kubectllabelnodesHOSTNAMErandom-key=random-value
Exercise n°3
Delete the key/value pair : random-key=random-value of the first node of the cluster.
kubectllabelnodesHOSTNAMErandom-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.
Create a namespace called voting-app
Update one node with the key/value label : type=database
Update another node with the key/value label : type=queue
Ensure each nodes are correctly configured
On single node cluster like Minikube, the key defined must be unique.