kubernetes-cli-basics-with-kubectl.html

Kubernetes Command-Line Basics

with `kubectl`

`bit.ly/k8s-kubectl`

presented by @ryanj, Developer Advocate at Red Hat

Overview

Kubernetes Basics
- Why Kubernetes?
- Learn five K8s Primitives

# Kubernetes Basics

Why Kubernetes?

Kubernetes is...

An open source platform for running container-based distributed solutions, featuring a modular, HA systems architecture
The best way to actively manage distributed solutions at scale, based on years of industry expertise (Google-scale experience)
An extensible distributed-solutions modeling language with a huge community following
A multi-vendor effort to eliminate cloud lock-in through the adoption of "cloud native" solutions (capable of runnning on any infrastructure)

Kubernetes provides… ## An API API object primitives include the following attributes: ``` kind apiVersion metadata spec status ``` *mostly true

### Basic K8s Terminology 1. [node](#/node) 2. [pod](#/po) 3. [service](#/svc) 4. [deployment](#/deploy) 5. [replicaSet](#/rs)

### Node A node is a host machine (physical or virtual) where containerized processes run. Node activity is managed via one or more Master instances.

Try using kubectl to list resources by type:

kubectl get nodes

Request the same info, but output the results as structured yaml:

kubectl get nodes -o yaml

Fetch an individual resource by type/id, output as json:

kubectl get node/minikube -o json

View human-readable API output:

kubectl describe node/minikube

### Observations: * Designed to exist on multiple machines (distributed system) * high availability of nodes * platform scale out * The API ambidextriously supports both json and yaml

### Pod A group of one or more co-located containers. Pods represent your minimum increment of scale. > "Pods Scale together, and they Fail together" @theSteve0

List resources by type:

kubectl get pods

Create a new resource based on a json object specification:

curl https://raw.githubusercontent.com/ryanj/metrics-k8s/master/pod.json

kubectl create -f https://raw.githubusercontent.com/ryanj/metrics-k8s/master/pod.json

List resources by type:

kubectl get pods

Fetch a resource by type and id, output the results as yaml:

kubectl get pod metrics-k8s -o yaml

Notice any changes?

### Observations: * pods are scheduled to be run on nodes * asyncronous fulfilment of requests * declarative specifications * automatic health checks, lifecycle management for containers (processes)

### Service Services (svc) establish a single endpoint for a collection of replicated pods, distributing inbound traffic based on label selectors In our K8s modeling language they represent a load balancer. Their implementation often varies per cloud provider

Contacting your App

Expose the pod by creating a new service (or "loadbalancer"):

kubectl expose pod/metrics-k8s --port 2015 --type=NodePort

Contact your newly-exposed pod using the associated service id:

minikube service metrics-k8s

Schedule a pod to be deleted:

kubectl delete pod metrics-k8s

Contact the related service. What happens?:

minikube service metrics-k8s

Delete the service:

kubectl delete service metrics-k8s

### Observations: * *"service"* basically means *"loadbalancer"* * Pods and Services exist independently, have disjoint lifecycles

### Deployment A `deployment` helps you specify container runtime requirements (in terms of pods)

Create a specification for your deployment:

kubectl run metrics-k8s --image=quay.io/ryanj/metrics-k8s \
--expose --port=2015 --service-overrides='{ "spec": { "type": "NodePort" } }' \
--dry-run -o yaml > deployment.yaml

View the generated deployment spec file:

cat deployment.yaml

Create a new resource based on your yaml specification:

kubectl create -f deployment.yaml

List resources by type:

kubectl get po,svc

Connect to your new deployment via the associated service id:

minikube service metrics-k8s

Replication

Scale up the metrics-k8s deployment to 3 replicas:

kubectl scale deploy/metrics-k8s --replicas=3

List pods:

kubectl get po

Edit deploy/metrics-k8s, setting spec.replicas to 5:

kubectl edit deploy/metrics-k8s -o json

Save and quit. What happens?

kubectl get pods

AutoRecovery

Watch for changes to pod resources:

kubectl get pods --watch

In another terminal, delete several pods by id:

kubectl delete pod $(kubectl get pods | grep ^metrics-k8s | cut -f1 -s -d' ' | head -n 3 | tr '\n' ' ')

What happend? How many pods remain?

kubectl get pods

### Observations: * Use the `--dry-run` flag to generate new resource specifications * A deployment spec contains a pod spec

### ReplicaSet A `replicaset` provides replication and lifecycle management for a specific image release

Watch deployments (leave this running until the 'cleanup' section):

kubectl get deploy --watch

View the current state of your deployment:

minikube service metrics-k8s

Rollouts

Update your deployment's image spec to rollout a new release:

kubectl set image deploy/metrics-k8s metrics-k8s=quay.io/ryanj/metrics-k8s:v1

Reload your browser to view the state of your deployment

kubectl get rs,deploy

Rollbacks

View the list of previous rollouts:

kubectl rollout history deploy/metrics-k8s

Rollback to the previous state:

kubectl rollout undo deployment metrics-k8s

Reload your browser to view the state of your deployment

Cleanup

Cleanup old resources if you don't plan to use them:

kubectl delete service,deployment metrics-k8s

Close any remaining --watch listeners

### Observations: * The API allows for watch operations (in addition to get, set, list) * ReplicaSets provide lifecycle management for pod resources * Deployments create ReplicaSets to manage pod replication per rollout (per change in podspec: image:tag, environment vars)