-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy path1-Architecture
99 lines (58 loc) · 4.45 KB
/
1-Architecture
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
kubernetes commands cheatsheet - https://kubernetes.io/docs/reference/kubectl/cheatsheet/
master node -
etcd cluster - stores the information about containers in the cluster
where and what containers are running
it stores data in a key valuse store.
ETCDCTL is the CLI tool used to interact with ETCD.
ETCDCTL can interact with ETCD Server using 2 API versions - Version 2 and Version 3. By default its set to use Version 2. Each version has different sets of commands.
For example ETCDCTL version 2 supports the following commands:
etcdctl backup
etcdctl cluster-health
etcdctl mk
etcdctl mkdir
etcdctl set
Whereas the commands are different in version 3
etcdctl snapshot save
etcdctl endpoint health
etcdctl get
etcdctl put
To set the right version of API set the environment variable ETCDCTL_API command
export ETCDCTL_API=3
When API version is not set, it is assumed to be set to version 2. And version 3 commands listed above don't work. When API version is set to version 3, version 2 commands listed above don't work.
Apart from that, you must also specify path to certificate files so that ETCDCTL can authenticate to the ETCD API Server. The certificate files are available in the etcd-master at the following path -
--cacert /etc/kubernetes/pki/etcd/ca.crt
--cert /etc/kubernetes/pki/etcd/server.crt
--key /etc/kubernetes/pki/etcd/server.key
So for the commands to work you must specify the ETCDCTL API version and path to certificate files. Below is the final form:
kubectl exec etcd-master -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl get / --prefix --keys-only --limit=10 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key"
--------------------------------------------------------------------------
kube scheduler - it deploys the containers or to workers based on two factors
1)how many resources(cpus) the container need (if a node has less cpus than the pod requres schuduler wont deploy it on that node)
2) how maany resources(cpus) will be left after deploying the pod(id two nodes have 14 and 16 cpus respectively and the pod need 10 cps , the pod will be deployed in the 16 cpu node as it has more cpus)
--------------------------------------------------------------------------
kude controller manager - it manages replication , node control
node controller - continously monitors the status of nodes and take necessary actions to keed nodes alive and it does through kube api server( node controller sends the request to kube api server and kube api server sends the requests to kubelet to get thge stratus of node)
the node controller gets the status of nodes every 5 seconds
if it stops getting heart beat from a node then the node is marked as unreachable ( node monitor grace period 40 seconds)
kube controller give the unreachable node 5 mins to come back online, if it doesnt then all the pods that were running on that nodes will be moved tha healthy nodes.
replication controller - it is responisible for maintaining the desired number of replicas
--------------------------------------------------------------------------
kube api server - its useful to talk to kubernets cluster
in order to deploy a pod in kubernetes it follows below steps
1) user is authenticated by kube api server
2) request is validated by kube api server
3)kube api server creaste a pod object without assaigning a node and then it is updated in etcd cluster
4)updated the user pod is created
5)scheduler continuously monitors api server and when it realises a pod is created , it assaigns a node to to the pod
6)kube api server updated the etcd cluster with the node.
7)kube api server passes the information to the kubelet on the worker node assaigned by scheduler
8)kubelet then creates the pod and instructs container runtime engine to deploy the application image
9) once deployment is done kublet updates the status back to kube api server
10)api server then updates the data in etcd cluster
This whole process is repeated for every pod deployment request
kube api server is the only service that talks directly to etcd cluster, rest all services use kube api server to talk to etcd cluster
--------------------------------------------------------------------------
worker node -
kubelet - this listens to instruction from kube api server and manages containers.
kube proxy -this enables comunication between different worker nodes
--------------------------------------------------------------------------