notes/session-69.txt at main · daws-88s/notes · GitHub

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
ingress old api vs new api
ingress api vs gateway api

target group binding

1. OIDC provider
2. policy and service account creation
3. aws load balancer controller drivers

eksctl create iamserviceaccount \
--cluster=roboshop-dev \
--namespace=kube-system \
--name=aws-load-balancer-controller \
--attach-policy-arn=arn:aws:iam::160885265516:policy/AWSLoadBalancerControllerIAMPolicy \
--override-existing-serviceaccounts \
--region us-east-1 \
--approve

eksctl delete iamserviceaccount \
--cluster=roboshop-dev \
--namespace=kube-system \
--name=aws-load-balancer-controller

helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=roboshop-dev --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller

blue green deployment
==================
Recreate -> stop the servers, remove old code, download new code, then start again
RollingUpdate -> slowly installing new servers/pods and removing old server/pods
no downtime, at this point of upgrade app serves both old and new version
Blue/Green ->

1. main service -> running version
2. preview service -> pointing to upcoming version

running version = blue
main service -> blue

new version = green
attach preview service to green
check internally, some health checks
if response is good
switch the route
then point main service to green -> live traffic
make blue replicas as 0

if rollback
make blue replicas as 2
again point main service to blue

double resources

version 0.0.1 -> blue

kubectl patch service nginx -p '{"spec":{"selector":{"version":"green"}}}'
kubectl patch deployment nginx-blue -p '{"spec":{"replicas":0}}'

present running -> green

new version blue -> 0.0.3
point preview service to blue
test it

if fine, then switch main service to blue

1. EKS platform, blue-nodegroup

2. Upgrade platform to new version 1.35 keep the blue-ng running in 1.34
3. Create another nodegroup green 1.35(this is automatic, because eks in 1.35)
4. cordon(scheduling disabled) blue nodes, then drain blue node slowly..

when there are platform upgrades, we announce defnitely downtime. 30min - 6hours
you face intermittent issues ->no downtime

terraform apply \
  -var="eks_version=1.35" \
  -var="eks_nodegroup_blue_version=1.34"

1. internal project teams, send your schedule -> before 3 months
2. update SG,cut the access to other teams

terraform apply \
  -var="eks_version=1.35" \
  -var="eks_nodegroup_blue_version=1.34" \
  -var="enable_green=true" \
  -var="eks_nodegroup_green_version=1.35"