Kubernetes Basics

Reading time: 20 minutes

Kubernetes Basics

इस पृष्ठ के मूल लेखक हैं Jorge (उनका मूल पोस्ट पढ़ें यहां)

Architecture & Basics

Kubernetes क्या करता है?

• कंटेनर/को कंटेनर इंजन में चलाने की अनुमति देता है।
• शेड्यूल कंटेनरों के मिशन को कुशल बनाता है।
• कंटेनरों को जीवित रखता है।
• कंटेनर संचार की अनुमति देता है।
• तैनाती तकनीकों की अनुमति देता है।
• जानकारी की मात्रा को संभालता है।

Architecture

• Node: ऑपरेटिंग सिस्टम जिसमें पॉड या पॉड्स होते हैं।
• Pod: एक कंटेनर या कई कंटेनरों के चारों ओर लपेटने वाला। एक पॉड में केवल एक एप्लिकेशन होना चाहिए (इसलिए आमतौर पर, एक पॉड केवल 1 कंटेनर चलाता है)। पॉड वह तरीका है जिससे Kubernetes कंटेनर तकनीक को अमूर्त करता है।
• Service: प्रत्येक पॉड के पास नोड के आंतरिक रेंज से 1 आंतरिक IP पता होता है। हालाँकि, इसे एक सेवा के माध्यम से भी उजागर किया जा सकता है। सेवा का भी एक IP पता है और इसका लक्ष्य पॉड्स के बीच संचार बनाए रखना है ताकि यदि एक मर जाता है तो नया प्रतिस्थापन (एक अलग आंतरिक IP के साथ) उसी सेवा के IP पर उपलब्ध होगा। इसे आंतरिक या बाहरी के रूप में कॉन्फ़िगर किया जा सकता है। सेवा तब लोड बैलेंसर के रूप में कार्य करती है जब 2 पॉड्स एक ही सेवा से जुड़े होते हैं।
  जब एक सेवा बनाई जाती है तो आप प्रत्येक सेवा के अंत बिंदुओं को kubectl get endpoints चलाकर पा सकते हैं।
• Kubelet: प्राथमिक नोड एजेंट। वह घटक जो नोड और kubectl के बीच संचार स्थापित करता है, और केवल पॉड्स चला सकता है (API सर्वर के माध्यम से)। Kubelet उन कंटेनरों का प्रबंधन नहीं करता है जो Kubernetes द्वारा नहीं बनाए गए थे।
• Kube-proxy: यह apiserver और नोड के बीच संचार (सेवाओं) का प्रभारी है। आधार नोड्स के लिए IPtables है। सबसे अनुभवी उपयोगकर्ता अन्य विक्रेताओं से अन्य kube-proxies स्थापित कर सकते हैं।
• Sidecar container: साइडकार कंटेनर वे कंटेनर हैं जो पॉड में मुख्य कंटेनर के साथ चलने चाहिए। यह साइडकार पैटर्न मौजूदा कंटेनरों की कार्यक्षमता को बढ़ाता और बढ़ाता है बिना उन्हें बदले। आजकल, हम जानते हैं कि हम एप्लिकेशन को कहीं भी चलाने के लिए सभी निर्भरताओं को लपेटने के लिए कंटेनर तकनीक का उपयोग करते हैं। एक कंटेनर केवल एक काम करता है और वह काम बहुत अच्छा करता है।
• Master process:
• Api Server: यह वह तरीका है जिससे उपयोगकर्ता और पॉड्स मास्टर प्रक्रिया के साथ संवाद करते हैं। केवल प्रमाणित अनुरोधों की अनुमति दी जानी चाहिए।
• Scheduler: शेड्यूलिंग का तात्पर्य यह सुनिश्चित करने से है कि पॉड्स को नोड्स से मिलाया जाए ताकि Kubelet उन्हें चला सके। इसमें यह तय करने के लिए पर्याप्त बुद्धिमत्ता है कि कौन सा नोड अधिक उपलब्ध संसाधनों के साथ है और नए पॉड को उसे सौंपता है। ध्यान दें कि शेड्यूलर नए पॉड्स शुरू नहीं करता है, यह केवल नोड के अंदर चल रहे Kubelet प्रक्रिया के साथ संवाद करता है, जो नए पॉड को लॉन्च करेगा।
• Kube Controller manager: यह संसाधनों की जांच करता है जैसे कि रिप्लिका सेट या तैनाती यह जांचने के लिए कि, उदाहरण के लिए, सही संख्या में पॉड्स या नोड्स चल रहे हैं। यदि कोई पॉड गायब है, तो यह एक नया शुरू करने के लिए शेड्यूलर के साथ संवाद करेगा। यह API के लिए प्रतिकृति, टोकन और खाता सेवाओं को नियंत्रित करता है।
• etcd: डेटा भंडारण, स्थायी, सुसंगत, और वितरित। यह Kubernetes का डेटाबेस है और कुंजी-मूल्य भंडारण है जहाँ यह क्लस्टरों की पूरी स्थिति को रखता है (यहाँ प्रत्येक परिवर्तन लॉग किया जाता है)। शेड्यूलर या कंट्रोलर प्रबंधक जैसे घटक इस डेटा पर निर्भर करते हैं यह जानने के लिए कि कौन से परिवर्तन हुए हैं (नोड्स के उपलब्ध संसाधन, चल रहे पॉड्स की संख्या...)।
• Cloud controller manager: यह प्रवाह नियंत्रण और अनुप्रयोगों के लिए विशिष्ट नियंत्रक है, यानी: यदि आपके पास AWS या OpenStack में क्लस्टर हैं।

ध्यान दें कि चूंकि कई नोड्स (कई पॉड्स चला रहे हैं) हो सकते हैं, इसलिए कई मास्टर प्रक्रियाएँ भी हो सकती हैं जिनका एपीआई सर्वर तक पहुंच लोड संतुलित होती है और उनका etcd समन्वयित होता है।

Volumes:

जब एक पॉड डेटा बनाता है जो पॉड के गायब होने पर नहीं खोना चाहिए, तो इसे एक भौतिक वॉल्यूम में संग्रहीत किया जाना चाहिए। Kubernetes एक पॉड में डेटा को स्थायी बनाने के लिए एक वॉल्यूम संलग्न करने की अनुमति देता है। वॉल्यूम स्थानीय मशीन में या दूरस्थ भंडारण में हो सकता है। यदि आप विभिन्न भौतिक नोड्स में पॉड्स चला रहे हैं, तो आपको एक दूरस्थ भंडारण का उपयोग करना चाहिए ताकि सभी पॉड्स इसे एक्सेस कर सकें।

अन्य कॉन्फ़िगरेशन:

• ConfigMap: आप सेवाओं तक पहुँचने के लिए URLs कॉन्फ़िगर कर सकते हैं। पॉड यहाँ से डेटा प्राप्त करेगा यह जानने के लिए कि बाकी सेवाओं (पॉड्स) के साथ कैसे संवाद करना है। ध्यान दें कि यह क्रेडेंशियल्स को सहेजने के लिए अनुशंसित स्थान नहीं है!
• Secret: यह गुप्त डेटा जैसे पासवर्ड, API कुंजी... को B64 में एन्कोड करने के लिए स्टोर करने का स्थान है। पॉड इस डेटा को आवश्यक क्रेडेंशियल्स का उपयोग करने के लिए एक्सेस कर सकेगा।
• Deployments: यह वह स्थान है जहाँ Kubernetes द्वारा चलाए जाने वाले घटकों को इंगित किया जाता है। एक उपयोगकर्ता आमतौर पर पॉड्स के साथ सीधे काम नहीं करेगा, पॉड्स को ReplicaSets (एक समान पॉड्स की संख्या) में अमूर्त किया जाता है, जिन्हें तैनातियों के माध्यम से चलाया जाता है। ध्यान दें कि तैनातियाँ stateless अनुप्रयोगों के लिए होती हैं। तैनाती के लिए न्यूनतम कॉन्फ़िगरेशन नाम और चलाने के लिए छवि है।
• StatefulSet: यह घटक विशेष रूप से डेटाबेस जैसे अनुप्रयोगों के लिए है जिन्हें एक ही भंडारण तक पहुँचने की आवश्यकता होती है।
• Ingress: यह वह कॉन्फ़िगरेशन है जिसका उपयोग URL के साथ अनुप्रयोग को सार्वजनिक रूप से उजागर करने के लिए किया जाता है। ध्यान दें कि यह बाहरी सेवाओं का उपयोग करके भी किया जा सकता है, लेकिन यह अनुप्रयोग को उजागर करने का सही तरीका है।
• यदि आप एक Ingress लागू करते हैं तो आपको Ingress Controllers बनाने की आवश्यकता होगी। Ingress Controller एक पॉड है जो वह अंत बिंदु होगा जो अनुरोध प्राप्त करेगा और उन्हें जांचेगा और सेवाओं के लिए लोड संतुलित करेगा। Ingress Controller कॉन्फ़िगर किए गए इनग्रेस नियमों के आधार पर अनुरोध भेजेगा। ध्यान दें कि इनग्रेस नियम विभिन्न पथों या यहां तक कि विभिन्न आंतरिक Kubernetes सेवाओं के लिए उपडोमेन की ओर इशारा कर सकते हैं।
• एक बेहतर सुरक्षा प्रथा यह होगी कि किसी भी Kubernetes क्लस्टर के भाग को उजागर न करने के लिए एक क्लाउड लोड बैलेंसर या प्रॉक्सी सर्वर का उपयोग किया जाए।
• जब कोई अनुरोध प्राप्त होता है जो किसी भी इनग्रेस नियम से मेल नहीं खाता है, तो इनग्रेस कंट्रोलर इसे "डिफ़ॉल्ट बैकएंड" की ओर निर्देशित करेगा। आप इस पैरामीटर के पते को प्राप्त करने के लिए इनग्रेस कंट्रोलर का describe कर सकते हैं।
• minikube addons enable ingress

PKI infrastructure - Certificate Authority CA:

• CA क्लस्टर के भीतर सभी प्रमाणपत्रों के लिए विश्वसनीय रूट है।
• घटकों को एक-दूसरे को मान्य करने की अनुमति देता है।
• सभी क्लस्टर प्रमाणपत्र CA द्वारा हस्ताक्षरित होते हैं।
• etcd का अपना प्रमाणपत्र है।
• प्रकार:
• apiserver cert.
• kubelet cert.
• scheduler cert.

Basic Actions

Minikube

Minikube का उपयोग Kubernetes पर कुछ त्वरित परीक्षण करने के लिए किया जा सकता है बिना पूरे Kubernetes वातावरण को तैनात किए। यह एक मशीन में मास्टर और नोड प्रक्रियाओं को चलाएगा। Minikube नोड चलाने के लिए वर्चुअलबॉक्स का उपयोग करेगा। यहां देखें कि इसे कैसे स्थापित करें।

$ minikube start
😄  minikube v1.19.0 on Ubuntu 20.04
✨  Automatically selected the virtualbox driver. Other choices: none, ssh
💿  Downloading VM boot image ...
> minikube-v1.19.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s
> minikube-v1.19.0.iso: 244.49 MiB / 244.49 MiB  100.00% 1.78 MiB p/s 2m17.
👍  Starting control plane node minikube in cluster minikube
💾  Downloading Kubernetes v1.20.2 preload ...
> preloaded-images-k8s-v10-v1...: 491.71 MiB / 491.71 MiB  100.00% 2.59 MiB
🔥  Creating virtualbox VM (CPUs=2, Memory=3900MB, Disk=20000MB) ...
🐳  Preparing Kubernetes v1.20.2 on Docker 20.10.4 ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by defaul

$ minikube status
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

---- ONCE YOU HAVE A K8 SERVICE RUNNING WITH AN EXTERNAL SERVICE -----
$ minikube service mongo-express-service
(This will open your browser to access the service exposed port)

$ minikube delete
🔥  Deleting "minikube" in virtualbox ...
💀  Removed all traces of the "minikube" cluster

Kubectl Basics

Kubectl क्यूबेरनेट्स क्लस्टर के लिए कमांड लाइन टूल है। यह क्यूबेरनेट्स में क्रियाएँ करने या डेटा मांगने के लिए मास्टर प्रक्रिया के एपीआई सर्वर के साथ संवाद करता है।

kubectl version #Get client and server version
kubectl get pod
kubectl get services
kubectl get deployment
kubectl get replicaset
kubectl get secret
kubectl get all
kubectl get ingress
kubectl get endpoints

#kubectl create deployment <deployment-name> --image=<docker image>
kubectl create deployment nginx-deployment --image=nginx
#Access the configuration of the deployment and modify it
#kubectl edit deployment <deployment-name>
kubectl edit deployment nginx-deployment
#Get the logs of the pod for debbugging (the output of the docker container running)
#kubectl logs <replicaset-id/pod-id>
kubectl logs nginx-deployment-84cd76b964
#kubectl describe pod <pod-id>
kubectl describe pod mongo-depl-5fd6b7d4b4-kkt9q
#kubectl exec -it <pod-id> -- bash
kubectl exec -it mongo-depl-5fd6b7d4b4-kkt9q -- bash
#kubectl describe service <service-name>
kubectl describe service mongodb-service
#kubectl delete deployment <deployment-name>
kubectl delete deployment mongo-depl
#Deploy from config file
kubectl apply -f deployment.yml

Minikube Dashboard

डैशबोर्ड आपको यह देखने की अनुमति देता है कि मिनीक्यूब क्या चला रहा है, आप इसे एक्सेस करने के लिए URL यहाँ पा सकते हैं:

minikube dashboard --url


🔌  Enabling dashboard ...
▪ Using image kubernetesui/dashboard:v2.3.1
▪ Using image kubernetesui/metrics-scraper:v1.0.7
🤔  Verifying dashboard health ...
🚀  Launching proxy ...
🤔  Verifying proxy health ...
http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/

YAML कॉन्फ़िगरेशन फ़ाइलों के उदाहरण

प्रत्येक कॉन्फ़िगरेशन फ़ाइल में 3 भाग होते हैं: metadata, specification (क्या लॉन्च करना है), status (इच्छित स्थिति)।
डिप्लॉयमेंट कॉन्फ़िगरेशन फ़ाइल की स्पेसिफिकेशन के अंदर आप टेम्पलेट पा सकते हैं जो चलाने के लिए इमेज को परिभाषित करने के लिए एक नई कॉन्फ़िगरेशन संरचना के साथ परिभाषित है:

एक ही कॉन्फ़िगरेशन फ़ाइल में घोषित Deployment + Service का उदाहरण (से यहाँ)

चूंकि एक सेवा आमतौर पर एक डिप्लॉयमेंट से संबंधित होती है, इसलिए दोनों को एक ही कॉन्फ़िगरेशन फ़ाइल में घोषित करना संभव है (इस कॉन्फ़िगरेशन में घोषित सेवा केवल आंतरिक रूप से सुलभ है):

apiVersion: apps/v1
kind: Deployment
metadata:
name: mongodb-deployment
labels:
app: mongodb
spec:
replicas: 1
selector:
matchLabels:
app: mongodb
template:
metadata:
labels:
app: mongodb
spec:
containers:
- name: mongodb
image: mongo
ports:
- containerPort: 27017
env:
- name: MONGO_INITDB_ROOT_USERNAME
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-username
- name: MONGO_INITDB_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-password
---
apiVersion: v1
kind: Service
metadata:
name: mongodb-service
spec:
selector:
app: mongodb
ports:
- protocol: TCP
port: 27017
targetPort: 27017

बाहरी सेवा कॉन्फ़िगरेशन का उदाहरण

यह सेवा बाहरी रूप से सुलभ होगी (चेक करें nodePort और type: LoadBlancer विशेषताएँ):

---
apiVersion: v1
kind: Service
metadata:
name: mongo-express-service
spec:
selector:
app: mongo-express
type: LoadBalancer
ports:
- protocol: TCP
port: 8081
targetPort: 8081
nodePort: 30000

Ingress कॉन्फ़िग फ़ाइल का उदाहरण

यह एप्लिकेशन को http://dashboard.com पर उजागर करेगा।

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: dashboard-ingress
namespace: kubernetes-dashboard
spec:
rules:
- host: dashboard.com
http:
paths:
- backend:
serviceName: kubernetes-dashboard
servicePort: 80

गुप्त कॉन्फ़िग फ़ाइल का उदाहरण

ध्यान दें कि पासवर्ड B64 में एन्कोडेड हैं (जो सुरक्षित नहीं है!)

apiVersion: v1
kind: Secret
metadata:
name: mongodb-secret
type: Opaque
data:
mongo-root-username: dXNlcm5hbWU=
mongo-root-password: cGFzc3dvcmQ=

ConfigMap का उदाहरण

एक ConfigMap वह कॉन्फ़िगरेशन है जो पॉड्स को दिया जाता है ताकि वे जान सकें कि अन्य सेवाओं को कैसे ढूंढना और उन तक पहुंचना है। इस मामले में, प्रत्येक पॉड को पता होगा कि नाम mongodb-service एक पॉड का पता है जिसके साथ वे संवाद कर सकते हैं (यह पॉड एक mongodb निष्पादित करेगा):

apiVersion: v1
kind: ConfigMap
metadata:
name: mongodb-configmap
data:
database_url: mongodb-service

फिर, एक deployment config के अंदर, इस पते को इस प्रकार निर्दिष्ट किया जा सकता है ताकि यह pod के env के अंदर लोड हो सके:

[...]
spec:
[...]
template:
[...]
spec:
containers:
- name: mongo-express
image: mongo-express
ports:
- containerPort: 8081
env:
- name: ME_CONFIG_MONGODB_SERVER
valueFrom:
configMapKeyRef:
name: mongodb-configmap
key: database_url
[...]

वॉल्यूम कॉन्फ़िगरेशन का उदाहरण

आप विभिन्न स्टोरेज कॉन्फ़िगरेशन yaml फ़ाइलों के उदाहरण https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes में पा सकते हैं।
ध्यान दें कि वॉल्यूम नामस्थान के अंदर नहीं हैं

नामस्थान

Kubernetes एक ही भौतिक क्लस्टर द्वारा समर्थित कई आभासी क्लस्टर का समर्थन करता है। इन आभासी क्लस्टरों को नामस्थान कहा जाता है। ये उन वातावरणों में उपयोग के लिए बनाए गए हैं जहाँ कई उपयोगकर्ता कई टीमों या परियोजनाओं में फैले हुए हैं। कुछ से लेकर दर्जनों उपयोगकर्ताओं वाले क्लस्टरों के लिए, आपको नामस्थान बनाने या उनके बारे में सोचने की आवश्यकता नहीं होनी चाहिए। आपको केवल नामस्थान का उपयोग करना शुरू करना चाहिए ताकि Kubernetes में तैनात प्रत्येक भाग के बेहतर नियंत्रण और संगठन हो सके।

नामस्थान नामों के लिए एक दायरा प्रदान करते हैं। संसाधनों के नाम को एक नामस्थान के भीतर अद्वितीय होना चाहिए, लेकिन नामस्थानों के बीच नहीं। नामस्थान एक-दूसरे के अंदर नहीं हो सकते और प्रत्येक Kubernetes संसाधन केवल एक नामस्थान में ही हो सकता है।

यदि आप मिनीक्यूब का उपयोग कर रहे हैं तो डिफ़ॉल्ट रूप से 4 नामस्थान हैं:

kubectl get namespace
NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

• kube-system: यह उपयोगकर्ताओं के लिए नहीं है और आपको इसे छूना नहीं चाहिए। यह मास्टर और kubectl प्रक्रियाओं के लिए है।
• kube-public: सार्वजनिक रूप से सुलभ डेटा। इसमें एक configmap है जो क्लस्टर की जानकारी रखता है।
• kube-node-lease: एक नोड की उपलब्धता निर्धारित करता है।
• default: वह नामस्थान जिसे उपयोगकर्ता संसाधन बनाने के लिए उपयोग करेगा।

#Create namespace
kubectl create namespace my-namespace

kubectl api-resources --namespaced=true #In a namespace
kubectl api-resources --namespaced=false #Not in a namespace

आप उस संदर्भ में सभी बाद के kubectl कमांड के लिए namespace को सहेज सकते हैं।

kubectl config set-context --current --namespace=<insert-namespace-name-here>

Helm

Helm Kubernetes के लिए पैकेज प्रबंधक है। यह YAML फ़ाइलों को पैकेज करने और उन्हें सार्वजनिक और निजी रिपॉजिटरी में वितरित करने की अनुमति देता है। इन पैकेजों को Helm Charts कहा जाता है।

helm search <keyword>

Helm एक टेम्पलेट इंजन भी है जो वेरिएबल के साथ कॉन्फ़िग फ़ाइलें उत्पन्न करने की अनुमति देता है:

Kubernetes रहस्य

एक Secret एक ऑब्जेक्ट है जो संवेदनशील डेटा जैसे पासवर्ड, टोकन या कुंजी को धारण करता है। ऐसी जानकारी अन्यथा एक Pod स्पेसिफिकेशन या एक इमेज में रखी जा सकती है। उपयोगकर्ता Secrets बना सकते हैं और सिस्टम भी Secrets बनाता है। एक Secret ऑब्जेक्ट का नाम एक मान्य DNS उपडोमेन नाम होना चाहिए। यहाँ पढ़ें the official documentation।

Secrets कुछ इस प्रकार हो सकते हैं:

• API, SSH Keys।
• OAuth टोकन।
• क्रेडेंशियल्स, पासवर्ड (सादा पाठ या b64 + एन्क्रिप्शन)।
• जानकारी या टिप्पणियाँ।
• डेटाबेस कनेक्शन कोड, स्ट्रिंग्स…।

Kubernetes में रहस्यों के विभिन्न प्रकार हैं

Secrets कैसे काम करते हैं:

निम्नलिखित कॉन्फ़िगरेशन फ़ाइल एक secret को परिभाषित करती है जिसे mysecret कहा जाता है जिसमें 2 कुंजी-मूल्य जोड़े username: YWRtaW4= और password: MWYyZDFlMmU2N2Rm होते हैं। यह एक pod को भी परिभाषित करता है जिसे secretpod कहा जाता है जो mysecret में परिभाषित username और password को पर्यावरण चर SECRET_USERNAME __ और __ SECRET_PASSWOR में उजागर करेगा। यह 0640 अनुमतियों के साथ mysecret के अंदर username रहस्य को /etc/foo/my-group/my-username पथ में भी माउंट करेगा।

apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
---
apiVersion: v1
kind: Pod
metadata:
name: secretpod
spec:
containers:
- name: secretpod
image: nginx
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
volumeMounts:
- name: foo
mountPath: "/etc/foo"
restartPolicy: Never
volumes:
- name: foo
secret:
secretName: mysecret
items:
- key: username
path: my-group/my-username
mode: 0640

kubectl apply -f <secretpod.yaml>
kubectl get pods #Wait until the pod secretpod is running
kubectl exec -it  secretpod -- bash
env | grep SECRET && cat /etc/foo/my-group/my-username && echo

Secrets in etcd

etcd एक सुसंगत और उच्च-उपलब्ध की-मान भंडार है जो सभी क्लस्टर डेटा के लिए Kubernetes बैकिंग स्टोर के रूप में उपयोग किया जाता है। चलिए etcd में संग्रहीत रहस्यों तक पहुँचते हैं:

cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd

आप देखेंगे कि सर्ट्स, कीज़ और यूआरएल फ़ाइल सिस्टम में स्थित हैं। एक बार जब आप इसे प्राप्त कर लेते हैं, तो आप etcd से कनेक्ट करने में सक्षम होंगे।

#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] health

ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] health

एक बार जब आप संचार स्थापित कर लेते हैं, तो आप रहस्यों को प्राप्त करने में सक्षम होंगे:

#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] get <path/to/secret>

ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] get /registry/secrets/default/secret_02

ETCD में एन्क्रिप्शन जोड़ना

डिफ़ॉल्ट रूप से सभी रहस्य सादा पाठ में etcd के अंदर संग्रहीत होते हैं जब तक कि आप एक एन्क्रिप्शन परत लागू नहीं करते। निम्नलिखित उदाहरण https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ पर आधारित है।

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
- identity: {}

उसके बाद, आपको kube-apiserver पर --encryption-provider-config ध्वज सेट करना होगा ताकि यह बनाए गए कॉन्फ़िग फ़ाइल के स्थान की ओर इशारा करे। आप /etc/kubernetes/manifest/kube-apiserver.yaml को संशोधित कर सकते हैं और निम्नलिखित पंक्तियाँ जोड़ सकते हैं:

containers:
- command:
- kube-apiserver
- --encriyption-provider-config=/etc/kubernetes/etcd/<configFile.yaml>

volumeMounts में स्क्रॉल करें:

- mountPath: /etc/kubernetes/etcd
name: etcd
readOnly: true

volumeMounts में hostPath तक स्क्रॉल करें:

- hostPath:
path: /etc/kubernetes/etcd
type: DirectoryOrCreate
name: etcd

डेटा के एन्क्रिप्टेड होने की पुष्टि करना

डेटा को etcd में लिखते समय एन्क्रिप्ट किया जाता है। अपने kube-apiserver को पुनरारंभ करने के बाद, कोई भी नया या अपडेट किया गया सीक्रेट स्टोर करते समय एन्क्रिप्ट किया जाना चाहिए। जांचने के लिए, आप अपने सीक्रेट की सामग्री को पुनः प्राप्त करने के लिए etcdctl कमांड लाइन प्रोग्राम का उपयोग कर सकते हैं।

1. default नामस्थान में secret1 नामक एक नया सीक्रेट बनाएं:

kubectl create secret generic secret1 -n default --from-literal=mykey=mydata

2. etcdctl कमांडलाइन का उपयोग करके, उस सीक्रेट को etcd से पढ़ें:

ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C

जहां [...] आदि सर्वर से कनेक्ट करने के लिए अतिरिक्त तर्क होना चाहिए।

3. पुष्टि करें कि स्टोर किया गया सीक्रेट k8s:enc:aescbc:v1: से प्रारंभ होता है, जो इंगित करता है कि aescbc प्रदाता ने परिणामी डेटा को एन्क्रिप्ट किया है।
4. पुष्टि करें कि API के माध्यम से पुनः प्राप्त करते समय सीक्रेट सही ढंग से डिक्रिप्ट किया गया है:

kubectl describe secret secret1 -n default

को mykey: bXlkYXRh से मेल खाना चाहिए, mydata को एन्कोड किया गया है, पूरी तरह से सीक्रेट को डिक्रिप्ट करने के लिए decoding a secret की जांच करें।

चूंकि सीक्रेट को लिखते समय एन्क्रिप्ट किया जाता है, इसलिए एक सीक्रेट पर अपडेट करना उस सामग्री को एन्क्रिप्ट करेगा:

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

अंतिम सुझाव:

• FS में रहस्य रखने से बचें, उन्हें अन्य स्थानों से प्राप्त करें।
• अपने रहस्यों को और अधिक सुरक्षा देने के लिए https://www.vaultproject.io/ पर जाएं।
• https://kubernetes.io/docs/concepts/configuration/secret/#risks
• https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm

संदर्भ

kubesectips v1 | sickrov.github.io

- YouTube