WHAT IS KUBERNETES
HOW DOES KUBERNETES WORKS
KUBERNETES FEATURES
KUBERNETES ARCHITECTURE
Master nodes (control-plane) controls and coordinates all the nodes and continuously maintaining the desired state throughout your cluster. Master process :
kube-apiserver the single point of management for the entire cluster. The API server implements a RESTful interface for communication with tools and libraries. The kubectl command directly interacts with the API server. Kube-apiserver jobs are :
kube-controller-manager which performs cluster-level functions, such as replicating components, keeping track of worker nodes, handling node failures, and so on.
kube-scheduler which schedules your apps (assigns a worker node to each deployable component of your application).
ETCD is a reliable distributed data store that persistently stores the cluster configuration. Kubernetes uses etcd to store configuration data that can be accessed by each of the nodes in the cluster. This can be used for service discovery and can help components configure or reconfigure themselves according to up-to-date information.
What is key-value store? store information in a key-value format in database, for example:
ETCD in kubernetes, store information regarding cluster such as Nodes, PODs, Configs, Secrets, Accounts, Roles, Binding, Others. If you setup kubernetes from scratch, you need to deploy and configure etcd server manually. If you setup cluster using kubeadm, then kubeadm deploys the etcd server as a pod in the kube-system namespace.
you can explore etcd database using etcdctl: kubectl exec etcd-master -n kube-system etcdctl get / --prefix -keys-only
Worker nodes. worker nodes are basically worker machines (VMs, physical, bare metal servers, etc) in a cluster running your workloads. The nodes are controlled by Kubernetes master and are continuously monitored to maintain the desired state of the application. Worker process :
Addons.
KUBERNETES OBJECTS
kubectl create -f pod-definition.yaml</br>
always contain 4 top level/properties (required) in the configuration file:
apiVersion:
kind:
metadata:
spec:
apiVersion: v1
kind: Pod [the types of object]
metadata: [data about of the object. like name/object/label ]
name: myapp-pod
labels:
app: myapp
type: front-end
spec: [dictionary]
containers: [list/array]
- name: nginx-container
image: nginx
- name: backend-container
apiVersion: v1
kind: Namespace
metadata:
name: dev
apiVersion: v1
kind: Pod
metadata:
name:myapp-pod
namespace: other-namespace
labels:
app: myapp
type: front-end
spec:
containers:
- name: nginx-controller
image: nginx
To limit resources in Namespaces, using ResourceQuota.
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-quota
namespace: dev
spec:
hard:
pods: "10"
requests.cpu: "4"
requests.memory: 5Gi
limits.cpu: "10"
limits.memory: 10Gi
KUBERNETES CONTROLLERS
ReplicationController and ReplicaSet
ReplicationController = older technology that is being replaced by ReplicaSet.
#ReplicationController
apiVersion: v1
kind: ReplicationController
metadata:
name: myapp-rc
labels:
app: myapp
type: front-end
spec:
template:
metadata:
name: myapp-pod
labels:
app: myapp
type: front-pod
spec:
containers:
- name: nginx-controller
image: nginx
replicas: 3
#ReplicaSet
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp-rs
labels:
app: myapp
type: front-end
spec:
template:
metadata:
name: myapp-pod
labels:
app: myapp
type: front-pod
spec:
containers:
- name: nginx-controller
image: nginx
replicas: 3
selector: #Necessary in ReplicaSet
matchLabels:
type: front-end
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
labels:
app: myapp
type: front-end
spec:
template:
metadata:
name: myapp-pod
labels:
app: myapp
type: front-pod
spec:
containers:
- name: nginx-controller
image: nginx
replicas: 3
selector:
matchLabels:
type: front-end
KUBERNETES NETWORKING
Kubernetes using three different types of networks :
Networking between components in kubernetes :
ACCESSING KUBERNETES CLUSTER
KUBERNETES SERVICE TYPE
KUBERNETES OBJECT MODEL
apiVersion: apps/v1 #apiVersion, API endpoint on API server which we want to connect to
kind: Deployment #kind, object type
metadata: #metadata, basic information of object
name: nginx-deployment
spec: #spec, desire state of deployment
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort:80
KUBERNETES VOLUME MANAGEMENT
KUBERNETES (KUBECTL) USEFULLL COMMAND
Help : kubectl -h
Syntax : kubectl [command] [TYPE] [NAME] [flags]
-- command : Specifies the operation (create, get, describe, delete)
-- type : Specifies the resource type.
-- name : Specifies the name of the resource.
-- flags : Specifies optional flags.
kubectl api-resources #Print the supported API resources on the server.
kubectl get apiservices #Print the supported API services on the server.
kubectl get all|endpoints|nodes|pods|deployments|services|secrets|replicaset|resourcequota -o wide|json|yaml
kubectl get all|endpoints|nodes|pods|deployments|services|secrets|replicaset|resourcequota --all-namespaces
kubectl cluster-info
kubectl config view
kubectl apply -f FILENAME [flags]
kubectl apply -f kubernetes-dashboard.yaml
kubectl create -f FILENAME [flags]
kubectl create namespaces app01
kubectl create secret ...
kubectl create -f app01.yaml
kubectl create 0f app01.yaml --namespace=name
kubectl delete
kubectl describe
kubectl edit
kubectl edit deployment apache02
kubectl exec POD
kubectl exec -it apache02 /bin/bash
kubectl expose [type] [name] [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type]
kubectl expose deployment apache02 --port=80 --protocol=TCP --type=NodePort --external-ip=103.x.x.x
kubectl expose pod redis --port=6379 --name redis-service --dry-run=client -o yaml
kubectl logs POD
kubectl logs apache02
kubectl run NAME --image=image [--port=port] [--replicas=replicas] [--labels]
kubectl run apache02 --image=httpd --port=80 --replicas=3 --labels="name=apache02"
#generate manifestasi yaml file, use --dry-run to not creating.
#deployment doesnt have replicas, so you can scale it later.
kubectl create deployment --image=nginx nginx --dry-run -o yaml
kubectl create deployment --image=nginx nginx --dry-run -o yaml > nginx-deployment.yaml
kubectl create service clusterip redis --tcp=6379:6379 --dry-run=client -o yaml
kubectl replace -f [file].yaml
kubectl scale -replicas=x -f [file].yaml
#changing default namespace
kubectl config set-context $(kubectl config current context) --namespace=x
Reference :
https://kubernetes.io/docs/reference/kubectl/overview/
https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#
https://kubernetes.io/docs/reference/kubectl/cheatsheet/
KUBERNETES SECRETS
A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in an image; putting it in a Secret object allows for more control over how it is used, and reduces the risk of accidental exposure.
Users can create secrets, and the system also creates some secrets.
To use a secret, a pod needs to reference the secret. A secret can be used with a pod in two ways: as files in a volume mounted on one or more of its containers, or used by kubelet when pulling images for the pod.
https://kubernetes.io/docs/concepts/configuration/secret/
GLOSARIUM
KUBERNETES BASIC MODULS
Reference : https://medium.com/sannycloud/apa-itu-kubernetes-k8s-af4e68f7c358