-
Notifications
You must be signed in to change notification settings - Fork 39
Expand file tree
/
Copy pathsession-70.txt
More file actions
154 lines (106 loc) · 4.4 KB
/
Copy pathsession-70.txt
File metadata and controls
154 lines (106 loc) · 4.4 KB
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
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
1. recreate
2. rolling update -> 2 versions running at same time
3. blue/green -> double cost, we can reduce replicas to 0
4. canary -> send traffic to diff version randomly, slowly ramping up from 0 to 100%
5. A/B testing -> sending some traffic to other version based on location, headers, etc
6. shadow -> v2 is running but not accepting live traffic, we mock live traffic live traffic from v1 to ve, but we dont send response to end user
switching route
blue
main service
green -> preview service -> endpoint testing
switch main service to green
1. upgrade control plan to next version, keeping blue current version
2. upgrade add-ons
3. create green ng with new version
4. cordon the blue node group, scheduling disabled
5. drain the blue node, workloads will go to green
6. remove blue ng
init containers
================
we must secrets in secretsmanager
MySQL pod, MYSQL_ROOT_PASSWORD is required to setup
we can use init containers, these are containers that before main container runs. it prepares the env for main container like fetching secrets, checking the dependency services, running some sql scripts
camping -> main
tent -> init container
init container runs to completion, you can have multiple init containers, they will be executed sequentially
1. we should have IAM policy that can fetch the secrets
2. create service account with this policy, IAM role will be created
3. run the pod with this service account.
4. create init container that fetches secret and make it available in certain location -> containers in the can share storage
5. main container reads it from shared location, export it as env variable and remove that file
/secrets/mysql-root-password.txt -> this is where init container fetches and stores the secret
arn:aws:iam::160885265516:policy/RoboshopMYSQLRootPasswordReader
eksctl create iamserviceaccount \
--name mysql-secret-reader \
--namespace roboshop \
--cluster roboshop-dev \
--attach-policy-arn arn:aws:iam::160885265516:policy/RoboshopMYSQLRootPasswordReader \
--role-name "RoboshopMySQLReader" \
--approve
aws secretsmanager get-secret-value --secret-id roboshop/dev/mysql_root_password --query SecretString --output text | jq -r .MYSQL_ROOT_PASSWORD
Networking
===========
VPC handles EKS networking, it treats pods as first class citizens. it allocates pod IP in VPC CIDR range...
Network interface
===========
How your system gets IP address. Ethernet, WiFi, Mobile Data, etc...
c3.large -> 3 ENI each interface can give 10 Ip = 30
1 Ip addres is for primary
29 secondary IP addresses we can have for pods
How many pods we are planning -> 100 pods
4 nodes
c3.xlarge -> 2
NetworkPolicy
1. shouldn't allows pods from differnet namespace. default deny for every pod in roboshop namespace
aws eks update-addon --cluster-name roboshop-dev --addon-name vpc-cni \
--configuration-values '{"enableNetworkPolicy": "true"}'
mongodb should accept connections from catalogue
mongodb should accept connections from redis
Pod Disruption Budget
=====================
1 pod in some node
if node down -> app down
node upgrade
cordon
drain
autoscaling -> nodes will be deleted
in voluntary disruptions pods may go down
we can define max how many number of pods can be unavailable
2 pods -> 1 pod can go to unavailable
2 nodes
node-1 -> pod-1 -> success
node-2 -> pod-2
node-2 -> pod-1 and pod-2
before draining PDB comes into action...
drain will be failed
node-3 -> pod-2 should come here
single pod replica -> 25% of pods
maxUnavailable -> 25%
minAvailable -> 25%
4 pods -> 1 pod should be always available
1 pod ->25% max unavailable -> 0.25 pods should be always available -> 0 pods unavailable
2 pods -> 25% max unavailable -> 0.5 -> 0 pods unavailable
3 pods -> min available 25% -> 0.75 -> 0 pods can be available -> can have downtime
4 -> 1 pod can go available
0.anything -> 0
10 pods -> 2
4 nodes
node-1 -> 4 pods -> 6 pods are available -> success
2 nodes
=======
node-1 -> 9 pods -> cant drain
PDB
TopologySpreadConstraints -> spreding pods across nodes based on topologyspread constraint
host as topology(border)
single AZ
2 nodes
NODE-1 -> 1 pod is here
NODE-2 -> 2 pod is here
us-east-1a and us-east-1b
1 pod in us-east-1a az and another pod in us-east-1b
topology is zone
host level topology
us-east-1a-> 2 nodes and us-east-1b-> 2nodes
1st topology is zone -> k8s spreads pods across multi AZ
2nd topology is host -> 2 pods in same az spread across multi hosts
exec /bin/node /app/server.js