Hindi - Ht Cloud

Kubernetes Basics

Kubernetes Basics

बढ़िया हैकिंग और लाभ प्राप्त करें!

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

Architecture & Basics

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

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

  • समय-सारणी कंटेनरों को कार्यक्षम बनाती है।

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

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

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

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

Architecture

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

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

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

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

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

  • साइडकार कंटेनर: साइडकार कंटेनर मुख्य कंटेनर के साथ पॉड में चलने वाले कंटेनर हैं। यह साइडकार पैटर्न मौजूदा क

PKI इंफ्रास्ट्रक्चर - प्रमाणपत्र प्राधिकरण CA:

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

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

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

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

  • प्रकार:

  • apiserver प्रमाणपत्र।

  • kubelet प्रमाणपत्र।

  • scheduler प्रमाणपत्र।

मूल कार्रवाई

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 मूलभूत

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: LoadBalancer गुणधर्म):

---
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

तो, एक डिप्लॉयमेंट कॉन्फ़िग के अंदर इस पते को निम्नलिखित तरीके से निर्दिष्ट किया जा सकता है ताकि यह पॉड के 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 फ़ाइलों के विभिन्न उदाहरण ढूंढ सकते हैं। ध्यान दें कि वॉल्यूम नेमस्पेस के अंदर नहीं हैं

नेमस्पेस

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

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

यदि आप minikube का उपयोग कर रहे हैं तो डिफ़ॉल्ट रूप से 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 और अन्य) किसी नेमस्पेस में होते हैं। हालांकि, नेमस्पेस संसाधन और नोड्स और परिस्थितिगत वॉल्यूम जैसे निम्न स्तरीय संसाधन नेमस्पेस में नहीं होते हैं। देखने के लिए कि कौन से 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>

हेल्म

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

helm search <keyword>

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

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

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

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

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

  • ओआथ टोकन।

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

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

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

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

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

अनचाहे

विशेषज्ञ निर्धारित डेटा (डिफ़ॉल्ट)

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 नामक एक पॉड परिभाषित करती है जिसमें mysecret में परिभाषित username और password को वातावरण चरों 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 एक सतत और उच्च उपलब्धता वाला कुंजी-मान-संग्रह है जो सभी क्लस्टर डेटा के लिए Kubernetes के बैकिंग स्टोर के रूप में उपयोग किया जाता है। चलिए etcd में संग्रहित रहस्यों तक पहुंचें:

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

आपको FS में सर्टिफिकेट, की और URL के स्थान का पता चलेगा। इसे प्राप्त करने के बाद, आप 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

जहां [...] etcd सर्वर से कनेक्ट करने के लिए अतिरिक्त आर्ग्यूमेंट होने चाहिए। 3. सत्यापित करें कि संग्रहीत सीक्रेट k8s:enc:aescbc:v1: से प्रारंभ होता है, जो इसका संकेत देता है कि aescbc प्रदाता ने परिणामस्वरूप डेटा को एन्क्रिप्ट किया है। 4. एपीआई के माध्यम से प्राप्त करने पर सीक्रेट सही ढंग से डिक्रिप्ट हो रहा है, इसे सत्यापित करें:

kubectl describe secret secret1 -n default

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

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

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

अंतिम सुझाव:

संदर्भ

kubesectips v1sickrov.github.io
हैकट्रिक्स का समर्थन करें और लाभ प्राप्त करें!
PreviousKubernetes PentestingNextPentesting Kubernetes Services

Last updated