- minikube start --wait=false
To start the Kubernetes minikube
- kubectl cluster-info
To get the cluster information
- kubectl get nodes
To get the running nodes
- kubectl get services
To get the services
- kubectl get deployment
To get the deployments
- kubectl get pv
To get persistent volumes
- kubectl get pvc
To get persistent volume claims
- kubectl get ing
To get the status of the ingress rules. Ingress rules are used to manage the routing.
- kubectl get all
To get all deployments or what are the things deployed?
- kubectl describe node
master01| grep "Container Runtime Version:"
Where master01 is the node name
Used describe command to grep the container runtime.
- kubectl get pods --all-namespaces
To get pods and namespaces
- kubectl set image deployment/http http=docker.io/sample/docker-http-server:latest
To create Pod based on Docker image. All images should be prefixed with container image registry. In the above case, it is Docker.
- kubectl apply -f dashboard.yaml
To deploy the dashboard yaml with command
- kubectl get pods -n kube-system
To get the Pods from kube-system namespace
- Pods
- Replication Controller
- Services
- NodePorts
Pod is a collection of Containers that make up a particular application.
kubectl get pods
The replication controller defines how many instances should be running, the Docker Image to use, and a name to identify the service.
Controller defines how the service runs.
kubectl get rc
To get Replication Controller.
Slave Pods are available.
A Kubernetes service is a named load balancer that proxies traffic to one or more containers. The proxy works even if the containers are on different nodes.
Use LoadBalancer service to handle external communications
kubectl get services
kubectl describe services <service name>
Slave service are available.
DNS
NodePort allows you to set well-known ports that are shared across your entire cluster. Such as 80:80.
kubectl describe service frontend | grep NodePort
To find NodePort from service. This is the port used for the webapp communication.
- NodePort exposes the service on each Node's IP via the defined static port
NFS server can be used to create persistent volume which can be used for stateful services such as MySQL, HTTP service etc.
Helm is the best way to find, share, and use software built for Kubernetes.
Helm is a single binary that manages deploying Charts to Kubernetes.
helm search redis
Search redis in package manager
helm inspect stable/redis
Get more info using Inspect command
helm install stable/redis To install redis
helm ls To view all packages
A chart is a packaged unit of kubernetes software. It can be downloaded from https://github.com/kubernetes/helm/releases
Weave Scope lets you monitor and control your containerized microservices applications. By providing a visual map of your Docker Containers, you can see the dependencies and communication links between them.
Scope automatically detects processes, containers, hosts. No kernel modules, no agents, no special libraries, no coding.
kubectl get pods -n weave
To check whether Weave is deployed in the pod
By default, once deployed it will only be accessible from inside the cluster.
You can expose outside the cluster using VPN.
- Used to visualize the containers
- Monitor the interactions between the containers
https://github.com/kubernetes/kubeadm
Kubeadm is a tool built to provide best-practice fast paths for creating Kubernetes clusters.
https://kubernetes.io/blog/2017/04/rbac-support-in-kubernetes/
Role-based access control, is an authorization mechanism for managing permissions around Kubernetes resources.
ABAC, Attribute Based Access Control, is a powerful concept. However, as implemented in Kubernetes, ABAC is difficult to manage and understand. It requires ssh and root filesystem access on the master VM of the cluster to make authorization policy changes. For permission changes to take effect the cluster API server must be restarted.
https://kubernetes.io/docs/setup/production-environment/container-runtimes/
To run containers in Pods, Kubernetes uses a container runtime. Here are the installation instructions for various runtimes.
- Docker
- CRI-O
- Containerd
- frakti - Hypervisor based
Because CRI-O is built for Kubernetes it means there are no Pause containers. This is just one of the many advantages of having a container runtime designed for Kubernetes.
- Hypervisor based container runtimes
- Linux-namespace-based container runtimes
The master is responsible for running the control plane components, etcd and the API server. Clients will communicate to the API to schedule workloads and manage the state of the cluster.
https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/
etcd is a consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data.
etcd is a leader-based distributed system. Ensure that the leader periodically send heartbeats on time to all followers to keep the cluster stable.
https://kubernetes.io/docs/concepts/cluster-administration/addons/
The Container Network Interface (CNI) defines how the different nodes and their workloads should communicate.
https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
When Kubernetes creates a Pod it assigns one of these QoS classes to the Pod:
- Guaranteed
- Burstable
- BestEffort
- Cluster IP - is the default approach when creating Kubernetes service
- Target Ports
- NodePort
- External IPs
- Load Balancer
- Port on which the application will be accessed from outside
- Port which the application is configured to listen on
Service can be accessed via the NodePort, TargetPort, ClusterIP and ExternalIP