In this LinuxFoundationX's LFS158x course, we'll discuss some of Kubernetes' basic concepts and talk about the architecture of the system, the problems it solves, and the model that it uses to handle containerized deployments and scaling.
This course offers an introduction to Kubernetes and includes technical instructions on how to deploy a stand-alone and multi-tier application. You’ll learn about ConfigMaps and Secrets, and how to use Ingress.
Instructor: Neependra Khare
With container images, we confine the application code, its runtime, and all of its dependencies in a pre-defined format. And, with container runtimes like runC, containerd, or rkt we can use those pre-packaged images, to create one or more containers. All of these runtimes are good at running containers on a single host. But, in practice, we would like to have a fault-tolerant and scalable solution, which can be achieved by creating a single controller/management unit, after connecting multiple nodes together. This controller/management unit is generally referred to as a Container Orchestrator.
Kubernetes offers a very rich set of features for container orchestration:
- Automatic binpacking
- Self-healing
- Horizontal scaling
- Service discovery and Load balancing
- Automated rollouts and rollbacks
- Secrets and configuration management
- Storage orchestration
- Batch execution
Cloud Native Computing Foundation (CNCF)
Kubernetes has the following main components:
- One or more Master Nodes
- API Server
- Scheduler
- Controller Manager
- One or more Worker Nodes
- Container Runtime
- kubelet
- kube-proxy
- Distributed key-value store, like etcd.
Kubernetes uses CNI to assign the IP address to each Pod.
- Container-to-Container Communication Inside a Pod
- Pod-to-Pod Communication Across Nodes
- Communication Between the External World and Pods
-
All-in-One Single-Node Installation
-
Single-Node etcd, Single-Master, and Multi-Worker Installation
-
Single-Node etcd, Multi-Master, and Multi-Worker Installation
-
Multi-Node etcd, Multi-Master, and Multi-Worker Installation
-
Localhost installation with Minikube
-
On-Premise Installation -- VMs or bare-metal
-
Cloud Installation -- GCP, AWS, Azure, etc.
$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.20.0/minikube-linux-amd64
$ chmod +x minikube
$ sudo mv minikube /usr/local/bin/
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
$ chmod +x ./kubectl
$ sudo mv ./kubectl /usr/local/bin/kubectl- kubectl Configuration File
minukubeandkubectlcommands- API calls
- minikube dashboard
- kubectl proxy
- Kubernetes Object Model
- Pods, labels and label selections
- Replica Set and Replication controller
- Deployments
- Namespaces
Kubernetes provides a higher-level abstraction called Service, which logically groups Pods and a policy to access them. This grouping is achieved via Labels and Selectors.
kube-proxy watches the API Server on the Master Node for the addition and removal of Services and endpoints. For each new Service, on each node, kube-proxy configures the IPtables rules to capture the traffic for its ClusterIP and forwards it to one of the endpoints. When the Service is removed, kube-proxy removes the IPtables rules on all nodes as well.
- Service discovery
- Environment variables
- DNS (core-dns)
- Service types
- ClusterIP
- NodePort
- LoadBalancer
- ExternalIP
- External Name
The LoadBalancer ServiceType will only work if the underlying infrastructure supports the automatic creation of Load Balancers and have the respective support in Kubernetes.
- Using the Minikube GUI
- Using the CLI
- Create a Service and Expose It to the External World with NodePort
A Volume is essentially a directory backed by a storage medium. The storage medium and its content are determined by the Volume Type.
-
Volume types
- emptyDir
- hostPath
- gcePersistentDisk
- awsElasticBlockStore
- nfs
- iscsi
- secret
- persistentVolumeClaim
-
Persistent Volumes
-
Persistent Volume Claims
- Deployment and service for MongoDB
- Deployment and service for the 'rsvp' Frontend
- Scale the Frontend
Using ConfigMaps, we can pass configuration details as key-value pairs, which can be later consumed by Pods, or any other system components, such as controllers. We can create ConfigMaps from:
- Literal values
- Files
$ kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2
$ kubectl create secret generic my-password --from-literal=password=mysqlpassword- Use ConfigMap Inside Pods:
- env.valueFrom.configMapKeyRef
- As a volume
- Use Secrets Inside Pods:
- env.valueFrom.secretKeyRef
- As a volume
An Ingress is a collection of rules that allow inbound connections to reach the cluster Services.
To allow the inbound connection to reach the cluster Services, Ingress configures a Layer 7 HTTP load balancer for Services and provides the following:
- TLS (Transport Layer Security)
- Name-based virtual hosting
- Path-based routing
- Custom rules
An Ingress Controller is an application which watches the Master Node's API Server for changes in the Ingress resources and updates the Layer 7 load balancer accordingly.
- Annotations
- Deployment rollback
- Jobs
- Quota Management
- Compute Resource Quota
- Storage Resource Quota
- Object Count Quota
- DaemonSets
- StatefulSets
- Role Based Access Control (RBAC)
- Kubernetes Federation
- Custom Resource Definition (CRD)
- Helm
- Logging and Monitoring
- Meetups
- Mailing Lists, Slack channels
- Special Interest Groups (SIGs)
- CNCF Events, KubeCon