Hindi - Ht Cloud

Kubernetes Basics

Kubernetes Basics

हैकट्रिक्स का समर्थन करें

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

वास्तुकला और मूल जानकारी

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

  • एक कंटेनर इंजन में कंटेनर/कंटेनर्स को चलाने की अनुमति देता है।

  • अनुसूची कंटेनरों को मिशन को अधिक कुशल बनाता है।

  • कंटेनरों को जीवित रखता है।

  • कंटेनर संचार की अनुमति देता है।

  • डिप्लॉयमेंट तकनीकों की अनुमति देता है।

  • जानकारी के वॉल्यूम का संभालन करता है।

वास्तुकला

  • नोड: पॉड या पॉड के साथ ऑपरेटिंग सिस्टम।

  • पॉड: एक कंटेनर या एकाधिक कंटेनर के चारों ओर लपेटने वाला। एक पॉड में केवल एक एप्लिकेशन होनी चाहिए (इसलिए सामान्यत: एक पॉड में केवल 1 कंटेनर चलता है)। पॉड कंटेनर प्रौद्योगिकी चलाने का तरीका है।

  • सेवा: प्रत्येक पॉड के पास नोड के आंतरिक आईपी पता होता है। हालांकि, इसे एक सेवा के माध्यम से भी उजागर किया जा सकता है। सेवा के पास भी एक आईपी पता होता है और इसका उद्देश्य पॉड्स के बीच संचार को बनाए रखना है, ताकि यदि कोई मर जाता है तो नया प्रतिस्थापन (एक विभिन्न आंतरिक आईपी के साथ) सेवा के समान आईपी में पहुंचने योग्य होगा। इसे आंतरिक या बाह्य रूप से कॉन्फ़िगर किया जा सकता है। सेवा जब बनाई जाती है तो आप प्रत्येक सेवा के एंडपॉइंट्स को चलाने के लिए kubectl get endpoints चला सकते हैं।

  • क्यूबलेट: प्राथमिक नोड एजेंट। उस घटक का जो नोड और कुबेक्टल के बीच संचार स्थापित करता है, और केवल पॉड्स को चला सकता है (API सर्वर के माध्यम से)। क्यूबलेट उन कंटेनरों का प्रबंधन नहीं करता जो कुबरनेट्स द्वारा नहीं बनाए गए हों।

  • क्यूब-प्रॉक्सी: यह सेवा एपीसर्वर और नोड के बीच संचार (सेवाएं) का जिम्मेदार है। आईपीटेबल्स के लिए नोड है। अधिक अनुभवी उपयोगकर्ता अन्य विक्रेताओं से अन्य क्यूब-प्रॉक्सी स्थापित कर सकते हैं।

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

  • मास्टर प्रक्रिया:

  • एपी सर्वर: उपयोगकर्ताओं और पॉड्स का मास्टर प्रक्रिया के साथ संवाद करने का तरीका है। केवल प्रमाणित अनुरोध को अनुमति देनी चाहिए।

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

  • क्यूब नियंत्रक प्रबंधक: यह संसाधनों जैसे कि रेप्लिका सेट्स या डिप्लॉयमेंट्स की जाँच करता है ताकि यदि, उदाहरण के लिए, सही संख्या के पॉड्स या नोड्स चल रहे हैं या नहीं। यदि कोई पॉड गायब है, तो यह नया शुरू करने के लिए स्केज्यूलर के साथ संवाद करेगा। यह प्रतिलिपि, टोकन और एपीआई की सेवाओं को नियंत्रित करता है।

  • etcd: डेटा संग्रहण, स्थायी, संगत और वितरित। कुबरनेट्स का डेटाबेस है और यहाँ पूरे क्लस्टर की स्थिति को रखता है (हर परिवर्तन यहाँ लॉग किया जाता है)। स्केज्यूलर या नियंत्रक प्रबंधक जैसे घटक जानने के लिए इस तिथि पर निर्भर करते हैं कि कौन से परिवर्तन हुए हैं (नोड्स के उपलब्ध संसाधन, चल रहे पॉड्स की संख्या...)

  • क्लाउड नियंत्रक प्रबंधक: यह विशेष नियंत्रक है जो फ्लो नियंत्रण और एप्लिकेशनों के लिए है, उदा: यदि आपके पास AWS या ओपनस्टैक में क्लस्टर हैं।

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

वॉल्यूम:

जब एक पॉड डेटा बनाता है जो पॉड गायब होने पर नष्ट नहीं होना चाहिए, तो उसे एक भौतिक वॉल्यूम में स्टोर किया जाना चाहिए। **कुबरनेट्स एक वॉल्यूम क

PKI बुनियादी संरचना - प्रमाणपत्र प्राधिकरण CA:

  • CA क्लस्टर के भीतर सभी प्रमाणपत्रों के लिए विश्वसनीय रूट है।

  • घटकों को एक-दूसरे को मान्य करने की अनुमति देता है।

  • सभी क्लस्टर प्रमाणपत्र CA द्वारा हस्ताक्षरित हैं।

  • ETCd का अपना प्रमाणपत्र है।

  • प्रकार:

    • एपीआई सर्टिफिकेट।

    • कुबलेट सर्टिफिकेट।

    • स्केज्यूलर सर्टिफिकेट।

मूल क्रियाएँ

Minikube

Minikube को पूरे कुबरनेटीज़ परिवेश को डिप्लॉय करने की आवश्यकता न होने पर कुबरनेटीज़ पर कुछ त्वरित परीक्षण करने के लिए उपयोग किया जा सकता है। यह मास्टर और नोड प्रक्रियाएँ एक मशीन में चलाएगा। 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

मिनीक्यूब डैशबोर्ड

डैशबोर्ड आपको आसानी से दिखाता है कि मिनीक्यूब क्या चला रहा है, आप इसे एक्सेस करने के लिए 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 भाग होते हैं: मेटाडेटा, विवरण (क्या लॉन्च करना है), स्थिति (वांछित स्थिति)। डिप्लॉयमेंट कॉन्फ़िगरेशन फ़ाइल के विवरण में, आप टेम्प्लेट पाएंगे जिसमें चलाने के लिए छवि को परिभाषित करने वाली एक नई कॉन्फ़िगरेशन संरचना होती है:

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

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

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

यह टेस्टिंग के लिए उपयोगी है लेकिन प्रोडक्शन के लिए आपके पास केवल आंतरिक सेवाएं होनी चाहिए और एक इंग्रेस एप्लिकेशन को बाहर निकालने के लिए।

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

यह एप्लिकेशन को 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

फिर, डिप्लॉयमेंट कॉन्फ़िगरेशन के अंदर इस पते को निम्नलिखित तरीके से निर्दिष्ट किया जा सकता है ताकि यह पॉड के 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
[...]

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

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

नेमस्पेस

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

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

अगर आप मिनीक्यूब का उपयोग कर रहे हैं तो डिफ़ॉल्ट रूप से 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: सार्वजनिक रूप से पहुंचने योग्य डेटा। एक कॉन्फ़िगमैप शामिल है जिसमें क्लस्टर सूचना होती है।

  • kube-node-lease: नोड की उपलब्धता निर्धारित करता है।

  • default: उपयोगकर्ता द्वारा संसाधन बनाने के लिए उपयोग किया जाएगा नेमस्पेस।

#Create namespace
kubectl create namespace my-namespace

ध्यान दें कि अधिकांश Kubernetes संसाधन (जैसे pods, services, replication controllers, और अन्य) किसी नेमस्पेस में होते हैं। हालांकि, अन्य संसाधन जैसे नेमस्पेस संसाधन और नोड्स और persistenVolumes जैसे निचले स्तर के संसाधन नेमस्पेस में नहीं होते हैं। देखने के लिए कौन से Kubernetes संसाधन नेमस्पेस में हैं और कौन नहीं:

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

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

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

हेल्म

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

helm search <keyword>

कुबरनेट्स सीक्रेट्स

सीक्रेट एक ऑब्जेक्ट है जो संवेदनशील डेटा जैसे पासवर्ड, टोकन या कुंजी जैसी जानकारी को शामिल करता है। ऐसी जानकारी अन्यथा एक पॉड स्पष्टीकरण या एक छवि में डाली जा सकती है। उपयोगकर्ता सीक्रेट बना सकते हैं और सिस्टम भी सीक्रेट बनाता है। सीक्रेट ऑब्जेक्ट का नाम एक मान्य DNS सबडोमेन नाम होना चाहिए। आधिकारिक दस्तावेज़ीकरण यहाँ पढ़ें।

सीक्रेट्स निम्नलिखित चीजें हो सकती हैं:

  • एपीआई, एसएसएच कुंजी।

  • ओआथ टोकन्स।

  • क्रेडेंशियल्स, पासवर्ड (सादा पाठ या b64 + एन्क्रिप्शन)।

  • जानकारी या टिप्पणियाँ।

  • डेटाबेस कनेक्शन कोड, स्ट्रिंग्स…।

कुबरनेट्स में विभिन्न प्रकार के सीक्रेट्स होते हैं

बिल्टइन प्रकारउपयोग

Opaque

अनियमित उपयोगकर्ता-निर्धारित डेटा (डिफ़ॉल्ट)

kubernetes.io/service-account-token

सेवा खाता टोकन

kubernetes.io/dockercfg

सिरियलाइज्ड ~/.dockercfg फ़ाइल

kubernetes.io/dockerconfigjson

सिरियलाइज्ड ~/.docker/config.json फ़ाइल

kubernetes.io/basic-auth

बुनियादी प्रमाणीकरण के लिए क्रेडेंशियल्स

kubernetes.io/ssh-auth

एसएसएच प्रमाणीकरण के लिए क्रेडेंशियल्स

kubernetes.io/tls

एक टीएलएस क्लाइंट या सर्वर के लिए डेटा

bootstrap.kubernetes.io/token

बूटस्ट्रैप टोकन डेटा

ओपेक प्रकार डिफ़ॉल्ट है, उपयोगकर्ताओं द्वारा परिभाषित साधारण की-मानक जोड़-मानक होता है।

सीक्रेट्स कैसे काम करते हैं:

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

secretpod.yaml
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

etcd में रहस्य

etcd एक संगत और उच्च उपलब्ध कुंजी-मूल्य संग्रह है जो सभी क्लस्टर डेटा के लिए कुबरनेट्स बैकिंग स्टोर के रूप में उपयोग किया जाता है। हम 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/ पर आधारित हैं

encryption.yaml
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>

संदर्भ माउंट में नीचे स्क्रॉल करें:

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

संदूषणों में नीचे जाएं 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

  1. 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 को एन्कोड किया गया है, सीक्रेट को पूरी तरह से डिकोड करने के लिए एक सीक्रेट को डिकोड करना देखें।

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

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

अंतिम सुझाव:

संदर्भ

हैकट्रिक्स का समर्थन करें
PreviousKubernetes PentestingNextPentesting Kubernetes Services

Last updated