-
Notifications
You must be signed in to change notification settings - Fork 39
Expand file tree
/
Copy pathsession-60.txt
More file actions
107 lines (82 loc) · 2.76 KB
/
Copy pathsession-60.txt
File metadata and controls
107 lines (82 loc) · 2.76 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
Volumes
========
storage admins
--------------
1. keep the storage secure
2. daily backup
3. restore
4. restore testing
5. replication -> another copy
6. archieval -> secondary
eks version upgrade
1. send a email to storage team
2. give them servers address
3. tell them to take the backup before upgrade
4. once they take backup, they respond it is completed
5. then we start upgrade
1. ephemeral volumes -> inside pods and hosts
2. eternal volumes
emptyDir
--------
1. containers in pod can share same storage..
2. create volume at the pod level
3. mount to the containers you want inside pod
in case of sidecar containers to read the storage and push the logs outside of cluster, we can use emptyDir
hostPath
-------
1. hostPath is not secure, we cant allow containers/pods to access host data.
2. but in rare cases we allow pods/conatiners to access hostPath in read-only mode
3. Daemonset makes sure of a pod replica runs on each and every worker node. while workernodes are adding to the cluster daemonset make sure a replica runs on new node also...
4. daemonset pod replicas access the underlying host information through hostpath volumes, and can ship it to the external clusters
Persistant volumes
Persistant volume claim
Storage class
1. send email to storage about disk creation. 100GB
2. disk id and how to connect
1. static provisioning
2. dynamic provisioning
EBS
=======================
1. HD should be as near as possible to server
2. EBS can be mounted to only one server at a time
3. EBS is faster than EFS
4. EBS is suitable for OS and databases because of low latency
we can use below access modes for EBS
1. ReadWriteOnce
2. ReadWriteOncePod
Reclaim policies
===========
Retain -> keep the disk and data even the node is deleted
Delete -> Delete the disk
Recycle -> Delete the data in disk, but keep the disk
vol-0b9fa8fe3f22c6bbe
drivers installtion
1. create the disk in the same az as your servers are in
2. install the ebs drivers for k8 to understand ebs
kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.58"
3. your worker nodes should ebs permission to mount the disk. attach AmazonEBSCSIDriverPolicy to the workernode IAM role to provide authorization
EFS
=====
1.
PV(Persistant Volume)
=====================
1. Physical representation of the disk
2. Equivalant object/resource for the disk inside k8S cluster
PVC
====
it is claiming the PV that it needs storage
kid -> mother -> father -> wallet
Pod -> PVC -> PV -> EBS
kid -> mother -> UPI wallet
Storage admins
==============
1. creating the disks
K8s admins
========
1. create PV
project/namespace devops engineer
========
1. create pvc and pod
StorageClass -> one time admin task
============
1. You can create disks and PV using storage class