CKA exam

• https://killer.sh/
• https://kubernetes.io/docs/
• https://kubernetes.io/blog/
• https://kubernetes.io/search/?q=kubecon
• https://github.com/kubernetes
• https://kubernetes.io/docs/reference/kubectl/cheatsheet/
• https://docs.linuxfoundation.org/tc-docs/certification/tips-cka-and-ckad

Useful aliases

• https://github.com/ahmetb/kubectl-aliases
• https://github.com/cloudmelon/melonkube/blob/master/00%20-%20Shortcuts.md

alias k=kubectl
alias kg='kubectl get'
alias kgpo='kubectl get pod'

cmds

kubectl config current-context            # check current context
kubectl config use-context cluster-name   # go to specific context
kubectl config get-contexts               # list of all contexts

Cluster architecture and components

The Kubernetes master node, or the control plane, is in charge of responding to the cluster events, and it contains the following components:

• API server: This is the core of the Kubernetes control plane. The main implementation of the API server, also known as kube-apiserver, is to expose the Kubernetes REST API. You can see it as a communication manager between different Kubernetes components across the Kubernetes cluster.
• etcd: This is a distributed key-value store that stores information regarding the cluster information and all states of objects running on the Kubernetes cluster, such as Kubernetes cluster nodes, Pods, config maps, secrets, service accounts, roles, and bindings.
• Kubernetes scheduler: A Kubernetes scheduler is a part of the control plane. It is responsible for scheduling Pods to the nodes. kube-scheduler is the default scheduler for Kubernetes. You can imagine it as a postal officer who sends the Pod’s information to each node and when it arrives at the target node, the kubelet agent on that node will provide the actual containerized workloads with the received specification.
• Controllers: Controllers are responsible for running Kubernetes toward the desired states. A set of built-in controllers runs inside kube-controller-manager in Kubernetes. Examples of those controllers are replication controllers, endpoint controllers, and namespace controllers.

Besides the control plane, every worker node in a Kubernetes cluster running the actual workloads has the following components:

• kubelet: A kubelet is an agent that runs on each worker node. It accepts pod specifications sent from the API server or locally (for static pod) and provisions the containerized workloads such as the Pod, StatefulSet, and ReplicaSet on the respective nodes.
• Container runtime: This is the software virtualization layer that helps run containers within the Pods on each node. Docker, CRI-O, and containerd are examples of common container runtimes working with Kubernetes.
• kube-proxy: This runs on each worker node and implements the network rules and traffic forwarding when a service object is deployed in the Kubernetes cluster.

Kubernetes basic workflow

• using kubectl commands, a YAML specification, or another way to invoke an API call, the API server creates a Pod definition and the scheduler identifies the available node to place the new Pod on.
• The scheduler does two things: filtering and scoring.
  • The filtering step finds a set of available candidate nodes to place the Pod
  • the scoring step ranks the most fitting Pod placement
• The API server then passes that information to the kubelet agent on the target worker node.
• The kubelet then creates the Pod on the node and instructs the container runtime engine to deploy the application image.
• Once it’s done, the kubelet communicates the status back to the API server, which then updates the data in the etcd store, and the user will be notified that the Pod has been created.

Kubernetes plugin model

One of the most important reasons for Kubernetes to dominate the market and become the new normal of the cloud-native ecosystem is that it is flexible, highly configurable, and has a highly extensible architecture. Kubernetes is highly configurable and extensible on the following layers:

• Container runtime: The container runtime is the lowest software virtualization layer running containers. This layer supports a variety of runtimes in the market thanks to the Container Runtime Interface (CRI) plugin. The CRI contains a set of protocol buffers, specifications, a gRPC API, libraries, and tools.
• Networking: The networking layer of Kubernetes is defined by kubenet or the Container Network Interface (CNI), which is responsible for configuring network interfaces for Linux containers, in our case, mostly Kubernetes Pods. The CNI is actually a Cloud Native Computing Foundation (CNCF) project that includes CNI specifications, plugins, and libraries.
• Storage: The storage layer of Kubernetes was one of the most challenging parts at a time prior to Container Storage Interface (CSI) being introduced as a standard interface for exposing block and file storage systems. The storage volumes are managed by storage drivers tailored by storage vendors, this part previously being part of Kubernetes source code. The CSI compatible volume drivers are served for users to attach or mount the CSI volumes to the Pods running in the Kubernetes cluster.

Kubernetes API primitives

• all operations and communications between components and external user commands are REST API calls that the API server handles.
• everything in Kubernetes is considered an API object.
• following are the main Kubernetes objects we’re going to use in our daily life while working with Kubernetes clusters:
  • Pods: The smallest deployable unit in Kubernetes is a Pod. The worker node hosts the Pods, which contain the actual application workload. The applications are packaged and deployed in the containers. A single Pod contains one or more containers.
  • ReplicaSet: ReplicaSet helps Pods achieve higher availability when users define a certain number of replicas at a time with a ReplicaSet. The role of the ReplicaSet is to make sure the cluster will always have an exact number of replicas up and running in the Kubernetes cluster. If any of them were to fail, new ones will be deployed.
  • DaemonSet: DaemonSet is like ReplicaSet but it makes sure at least one copy of your Pod is evenly presented on each node in the Kubernetes cluster. If a new node is added to the cluster, a replica of that Pod is automatically assigned to that node. Similarly, when a node is removed, the Pod is automatically removed.
  • StatefulSet: StatefulSet is used to manage stateful applications. Users can use StatefulSet when a storage volume is needed to provide persistence for the workload.
  • Job: A job can be used to reliably execute a workload automatically. When it completes, typically, a job will create one or more Pods. After the job is finished, the containers will exit and the Pods will enter the Completed status. An example of using jobs is when we want to run a workload with a particular purpose and make sure it runs once and succeeds.
  • CronJob: CronJobs are based on the capability of a job by adding value to allow users to execute jobs on a schedule. Users can use a cron expression to define a particular schedule per requirement.
  • Deployment: A Deployment is a convenient way where you can define the desired state Deployment, such as deploying a ReplicaSet with a certain number of replicas, and it is easy to roll out and roll back to the previous versions.

Update

https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/

kubectl version --client
kubectl version --client --output=yaml
kubectl cluster-info
kubectl cluster-info dump