kubelet runs and manages the containers on the node and talks to the API server
kube-proxy load balances traffic among the application components
container runtime: the program that runs the container (docker etc)
once you describe the image of application
1. scheduler on master node schedule the group of containers on to the nodes
2. then the kubelets instructs the container runtime(docker) to pull the images(image registry) and run the containers
Kubernetes API Primitives
every single K8 system components communicate with K8-API server.
K8-API server only communicates with etcd data store
cloud_user@jubayer1c:~$ kubectl get componentstatus
NAME STATUS MESSAGE ERROR
controller-manager Healthy ok
scheduler Healthy ok
etcd-0 Healthy {"health": "true"}
cat > nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
busybox 1/1 Running 106 8d <none>
nginx-deployment-5c689d88bb-6wk88 1/1 Running 0 126m app=nginx,pod-template-hash=5c689d88bb
nginx-deployment-5c689d88bb-dvp42 1/1 Running 0 126m app=nginx,pod-template-hash=5c689d88bb
web-757b94795b-qhd4f 0/1 CrashLoopBackOff 198 5d22h io.kompose.service=web,pod-template-hash=757b94795b
cloud_user@jubayer1c:~$ kubectl labels pods nginx-deployment-5c689d88bb-6wk88 env=prod
Error: unknown command "labels" for "kubectl"
Did you mean this?
label
Run 'kubectl --help' for usage.
unknown command "labels" for "kubectl"
Did you mean this?
label
cloud_user@jubayer1c:~$ kubectl label pods nginx-deployment-5c689d88bb-6wk88 env=prod
pod/nginx-deployment-5c689d88bb-6wk88 labeled
cloud_user@jubayer1c:~$ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
busybox 1/1 Running 106 8d <none>
nginx-deployment-5c689d88bb-6wk88 1/1 Running 0 128m app=nginx,env=prod,pod-template-hash=5c689d88bb
nginx-deployment-5c689d88bb-dvp42 1/1 Running 0 128m app=nginx,pod-template-hash=5c689d88bb
web-757b94795b-qhd4f 0/1 CrashLoopBackOff 198 5d22h io.kompose.service=web,pod-template-hash=757b94795b
cloud_user@jubayer1c:~$ kubectl get pods -L env
NAME READY STATUS RESTARTS AGE ENV
busybox 1/1 Running 106 8d
nginx-deployment-5c689d88bb-6wk88 1/1 Running 0 129m prod
nginx-deployment-5c689d88bb-dvp42 1/1 Running 0 129m
web-757b94795b-qhd4f 0/1 CrashLoopBackOff 199 5d22h
cloud_user@jubayer1c:~$ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 10d
nginx-nodeport NodePort 10.103.222.153 <none> 80:30080/TCP 11m
cloud_user@jubayer1c:~$ kubectl get service nginx-nodeport
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-nodeport NodePort 10.103.222.153 <none> 80:30080/TCP 13
Installing Kubernetes Master and Nodes
same as kubernetes
Configuring Secure Cluster Communications
View the kube-config:
cat .kube/config | more
View the service account token:
kubectl get secrets
Create a new namespace named my-ns:
kubectl create ns my-ns
Run the kube-proxy pod in the my-ns namespace:
kubectl run test --image=chadmcrowell/kubectl-proxy -n my-ns
List the pods in the my-ns namespace:
kubectl get pods -n my-ns
Run a shell in the newly created pod:
kubectl exec -it <name-of-pod> -n my-ns sh
List the services in the namespace via API call:
curl localhost:8001/api/v1/namespaces/my-ns/services
Lecture: Running End-to-End Tests on Your Cluster
Run a simple nginx deployment:
kubectl run nginx --image=nginx
View the deployments in your cluster:
kubectl get deployments
View the pods in the cluster:
kubectl get pods
Use port forwarding to access a pod directly:
kubectl port-forward $pod_name 8081:80
Get a response from the nginx pod directly:
curl --head http://127.0.0.1:8081
View the logs from a pod:
kubectl logs $pod_name
kubectl exec -it <nginx> -- nginx -v
Lecture: Upgrading the Kubernetes Cluster
kubeadm allows us to upgrade our cluster components in the proper order, making sure to include important feature upgrades we might want to take advantage of in the latest stable version of Kubernertes. In this lesson, we will go through upgrading our cluster from version 1.13.5 to 1.14.1.
Get the version of the API server:
kubectl version --short
View the version of kubelet:
kubectl describe nodes
View the version of controller-manager pod:
kubectl get po [controller_pod_name] -o yaml -n kube-system
Release the hold on versions of kubeadm and kubelet:
sudo apt-mark unhold kubeadm kubelet
Install version 1.14.1 of kubeadm:
sudo apt install -y kubeadm=1.14.1-00
Hold the version of kubeadm at 1.14.1:
sudo apt-mark hold kubeadm
Verify the version of kubeadm:
kubeadm version
Plan the upgrade of all the controller components:
sudo kubeadm upgrade plan
Upgrade the controller components:
sudo kubeadm upgrade apply v1.14.1
Release the hold on the version of kubectl:
sudo apt-mark unhold kubectl
Upgrade kubectl:
sudo apt install -y kubectl=1.14.1-00
Hold the version of kubectl at 1.14.1:
sudo apt-mark hold kubectl
Upgrade the version of kubelet:
sudo apt install -y kubelet=1.14.1-00
Hold the version of kubelet at 1.14.1:
sudo apt-mark hold kubelet
Lecture: Operating System Upgrades within a Kubernetes Cluster
When we need to take a node down for maintenance, Kubernetes makes it easy to evict the pods on that node, take it down, and then continue scheduling pods after the maintenance is complete. Furthermore, if the node needs to be decommissioned, you can just as easily remove the node and replace it with a new one, joining it to the cluster.
See which pods are running on which nodes:
kubectl get pods -o wide
Evict the pods on a node:
kubectl drain [node_name] --ignore-daemonsets
Watch as the node changes status:
kubectl get nodes -w
Schedule pods to the node after maintenance is complete:
kubectl uncordon [node_name]
Remove a node from the cluster:
kubectl delete node [node_name]
Generate a new token:
sudo kubeadm token generate
List the tokens:
sudo kubeadm token list
Print the kubeadm join command to join a node to the cluster:
sudo kubeadm token create [token_name] --ttl 2h --print-join-command
Lecture: Backing Up and Restoring a Kubernetes Cluster
Backing up your cluster can be a useful exercise, especially if you have a single etcd cluster, as all the cluster state is stored there. The etcdctl utility allows us to easily create a snapshot of our cluster state (etcd) and save this to an external location. In this lesson, we’ll go through creating the snapshot and talk about restoring in the event of failure.
Get the etcd binaries:
wget https://github.com/etcd-io/etcd/releases/download/v3.3.12/etcd-v3.3.12-linux-amd64.tar.gz
Unzip the compressed binaries:
tar xvf etcd-v3.3.12-linux-amd64.tar.gz
Move the files into /usr/local/bin:
sudo mv etcd-v3.3.12-linux-amd64/etcd* /usr/local/bin
Take a snapshot of the etcd datastore using etcdctl:
sudo ETCDCTL_API=3 etcdctl snapshot save snapshot.db --cacert /etc/kubernetes/pki/etcd/server.crt --cert /etc/kubernetes/pki/etcd/ca.crt --key /etc/kubernetes/pki/etcd/ca.key
View the help page for etcdctl:
ETCDCTL_API=3 etcdctl --help
Browse to the folder that contains the certificate files:
cd /etc/kubernetes/pki/etcd/
View that the snapshot was successful:
ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshot.db
Zip up the contents of the etcd directory:
sudo tar -zcvf etcd.tar.gz /etc/kubernetes/pki/etcd
Copy the etcd directory to another server:
scp etcd.tar.gz cloud_user@18.219.235.42:~/
