Kubernetes
This article goes over concepts as I try to understand everything about Kubernetes.
Installing
Master Node
# firewall-cmd --permanent --add-port=6443/tcp
# firewall-cmd --permanent --add-port=2379-2380/tcp
# firewall-cmd --permanent --add-port=10250/tcp
# firewall-cmd --permanent --add-port=10251/tcp
# firewall-cmd --permanent --add-port=10252/tcp
# firewall-cmd --permanent --add-port=10255/tcp
# firewall-cmd --reload
# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
# systemctl enable docker kubelet
# systemctl start docker kubelet
# kubeadm init
# export kubever=$(kubectl version
Once everything finishes running, it may take a few more minutes before the node becomes ready as the WeaveWorks network containers get pulled and started.
Worker Nodes
TBW
Concepts
Nodes
A node can take on the role of master or worker. A master node contains containers that provide the API server, scheduler, etc. that manages the cluster. The scheduler will generally place containers on worker nodes if possible.
Pods
A pod is:
- A collection of application containers
- Guaranteed to land on the same kubernetes cluster machine
- Shares the same cgroup, IP address, hostname (hence, runs in the same execution environment)
A pod should provide one individual component of an application that can:
- Be scaled independently of all other components in the application (eg. Database with respect to the frontend web server)
- Work even if placed (ie. orchestrated) on a different machine
In general, the right question to ask yourself when designing Pods is, “Will these containers work correctly if they land on different machines?” If the answer is “no,” a Pod is the correct grouping for the containers. If the answer is “yes,” multiple Pods is probably the correct solution. In the example at the beginning of this chapter, the two containers interact via a local filesystem. It would be impossible for them to operate correctly if the containers were scheduled on different machines.—Thinking with Pods, Kubernetes: Up and Running
Pods are defined in text file as a manifest. The Kubernetes API server processes the manifest, then stores it in persistent storage (etcd). A scheduler then finds pods that need to be scheduled and deploys the pods on the appropriate resource that satisfies any constraints defined in the manifest.
Creating
Imperative: kubectl run kuard --image=registry/something/something:tag
Manifest looks like this. A pod can be created by using the kubectl apply -f pod-manifest.yml command to load the manifest.
apiVersion: v1
kind: Pod
metadata:
name: kuard
spec:
containers:
- image: gcr.io/kuar-demo/kuard-amd64:1
name: kuard
ports:
- containerPort: 8080
name: http
protocol: TCP
See it running using kubectl get pods. Information of pods can be found by running kubectl describe pods pod-name. Pods can be deleted with kubectl delete pods/pod-name, or by passing in the manifest: kubectl delete -f pod-manifest.yml.
Pods that are set for deletion will cease to have new requests sent to it. After a 30 second termination grace period, the pods are then terminated. This extra time allows for the pod to reliably finish active requests.
Commands
| Description | Command |
|---|---|
| Get all nodes | # kubectl get nodes
|
| Get all pods | # kubectl get pods --all-namespaces
|
| Get information about a node | # kubectl describe nodes
|
Questions
- What is involved in setting up a cluster on multiple VMs?
- What is the Kubernetes API?
- What is this persistent storage (etcd)?
- What is the WeaveWorks network and how does it work?
See Also
- Kubernetes: Up & Running