This is the multi-page printable view of this section. Click here to print.
कुबेरनेट्स प्रलेखन के इस खंड के पृष्ठ एकल कार्य करने का तरीका दिखाते हैं। आमतौर पर, कार्य पृष्ठ दिखाता है कि किसी एक काम को कई छोटे चरणों में विभाजित करके कैसे करना है।
यदि आप एक कार्य पृष्ठ लिखना चाहते हैं, तो देखें प्रलेखन के लिए एक पुल अनुरोध (Pull Request) बनाएं.
यह पृष्ठ आपको दिखाता है कि kubectl कमांड-लाइन टूल का उपयोग करके कुबेरनेट्स
Secrets कैसे बनाएं, संपादित करें, प्रबंधित करें और हटाएं।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
एक Secret object संवेदनशील डेटा जैसे कि क्रेडेंशियल्स को स्टोर करता है
जिनका उपयोग Pods सेवाओं तक पहुंचने के लिए करते हैं। उदाहरण के लिए, आपको एक Secret की आवश्यकता हो सकती है
डेटाबेस तक पहुंचने के लिए आवश्यक username और password को स्टोर करने के लिए।
आप कमांड में raw data पास करके, या उन क्रेडेंशियल्स को फ़ाइलों में स्टोर करके Secret बना सकते हैं
जिन्हें आप कमांड में पास करते हैं। निम्नलिखित कमांड
एक Secret बनाते हैं जो username admin और password S!B\*d$zDsb= को स्टोर करता है।
निम्नलिखित कमांड चलाएं:
kubectl create secret generic db-user-pass \
--from-literal=username=admin \
--from-literal=password='S!B\*d$zDsb='
आपको विशेष वर्णों जैसे $, \,
*, =, और ! को अपने strings में escape करने के लिए single quotes '' का उपयोग करना चाहिए। यदि आप ऐसा नहीं करते हैं, तो आपका shell इन वर्णों की व्याख्या करेगा।
stringData फ़ील्ड server-side apply के साथ अच्छी तरह से काम नहीं करता है।क्रेडेंशियल्स को फ़ाइलों में स्टोर करें:
echo -n 'admin' > ./username.txt
echo -n 'S!B\*d$zDsb=' > ./password.txt
-n flag यह सुनिश्चित करता है कि उत्पन्न फ़ाइलों में
टेक्स्ट के अंत में एक अतिरिक्त newline वर्ण नहीं होता है। यह महत्वपूर्ण है क्योंकि जब kubectl
एक फ़ाइल पढ़ता है और सामग्री को base64 string में encode करता है, तो अतिरिक्त
newline वर्ण भी encode हो जाता है। आपको फ़ाइल में शामिल strings में विशेष वर्णों को escape करने की आवश्यकता नहीं है।
kubectl कमांड में फ़ाइल paths पास करें:
kubectl create secret generic db-user-pass \
--from-file=./username.txt \
--from-file=./password.txt
डिफ़ॉल्ट key name फ़ाइल का नाम है। आप वैकल्पिक रूप से key name सेट कर सकते हैं
--from-file=[key=]source का उपयोग करके। उदाहरण के लिए:
kubectl create secret generic db-user-pass \
--from-file=username=./username.txt \
--from-file=password=./password.txt
किसी भी विधि के साथ, आउटपुट इस प्रकार है:
secret/db-user-pass created
जांचें कि Secret बनाया गया था:
kubectl get secrets
आउटपुट इस प्रकार है:
NAME TYPE DATA AGE
db-user-pass Opaque 2 51s
Secret का विवरण देखें:
kubectl describe secret db-user-pass
आउटपुट इस प्रकार है:
Name: db-user-pass
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password: 12 bytes
username: 5 bytes
kubectl get और kubectl describe कमांड डिफ़ॉल्ट रूप से एक Secret की सामग्री को दिखाने से बचते हैं।
यह Secret को गलती से exposed होने से, या terminal log में stored होने से बचाने के लिए है।
आपके द्वारा बनाए गए Secret की सामग्री देखें:
kubectl get secret db-user-pass -o jsonpath='{.data}'
आउटपुट इस प्रकार है:
{ "password": "UyFCXCpkJHpEc2I9", "username": "YWRtaW4=" }
password डेटा को डिकोड करें:
echo 'UyFCXCpkJHpEc2I9' | base64 --decode
आउटपुट इस प्रकार है:
S!B\*d$zDsb=
kubectl get secret db-user-pass -o jsonpath='{.data.password}' | base64 --decode
आप एक मौजूदा Secret object को संपादित कर सकते हैं जब तक कि यह
immutable नहीं है। एक Secret को संपादित करने के लिए, निम्नलिखित कमांड चलाएं:
kubectl edit secrets <secret-name>
यह आपके डिफ़ॉल्ट editor को खोलता है और आपको base64 encoded
Secret values को data फ़ील्ड में अपडेट करने की अनुमति देता है, जैसे निम्नलिखित उदाहरण में:
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file, it will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
password: UyFCXCpkJHpEc2I9
username: YWRtaW4=
kind: Secret
metadata:
creationTimestamp: "2022-06-28T17:44:13Z"
name: db-user-pass
namespace: default
resourceVersion: "12708504"
uid: 91becd59-78fa-4c85-823f-6d44436242ac
type: Opaque
एक Secret को हटाने के लिए, निम्नलिखित कमांड चलाएं:
kubectl delete secret db-user-pass
कुबेरनेट्स कमांड-लाइन टूल, kubectl, आपको कुबेरनेट्स क्लस्टर पर कमांड चलाने की अनुमति देता है।
आप एप्लिकेशन को डिप्लॉय करने, क्लस्टर संसाधनों का निरीक्षण और प्रबंधन करने और लॉग देखने के लिए kubectl का उपयोग कर सकते हैं।
kubectl संचालन की पूरी सूची सहित अधिक जानकारी के लिए, देखें
kubectl संदर्भ प्रलेखन.
kubectl विभिन्न प्रकार के Linux प्लेटफॉर्म, macOS और Windows पर इंस्टॉल करने योग्य है। नीचे अपना उपयुक्त ऑपरेटिंग सिस्टम खोजें।
kind आपको अपने कंप्यूटर पर कुबेरनेट्स चलाने देता है।
इस उपकरण के लिए आवश्यक है कि आपके पास
Docker इंस्टॉल और कॉन्फ़िगर किया गया हो।
kind क्विक स्टार्ट पृष्ठ आपको दिखाता है कि kind चलाने के लिए आपको क्या करने की आवश्यकता है।
kind की तरह, minikube एक उपकरण
है जो आपको स्थानीय स्तर पर कुबेरनेट्स चलाने देता है। minikube आपके कंप्यूटर
(windows, macOS और linux पीसी सहित) पर सिंगल-नोड कुबेरनेट्स क्लस्टर चलाता
है ताकि आप कुबेरनेट्स सीख सकें या डेवलपमेंट कर सकें।
यदि आपका ध्यान उपकरण को इंस्टॉल करने पर है तो आप मुख्य आरंभ करें! गाइड का अनुसरण कर सकते हैं।
minikube क्विक स्टार्ट गाइड देखें
एक बार जब आपके पास minikube काम कर रहा हो, तो आप इसका उपयोग नमूना एप्लिकेशन चलाने के लिए कर सकते हैं।
कुबेरनेट्स क्लस्टर बनाने और प्रबंधित करने के लिए आप kubeadm टूल का उपयोग कर सकते हैं। यह उपयोगकर्ता के अनुकूल तरीके से न्यूनतम व्यवहार्य, सुरक्षित क्लस्टर बनाने और चलाने के लिए आवश्यक कार्य करता है।
kubeadm इंस्टॉल करना आपको दिखाता है कि kubeadm को कैसे इंस्टॉल किया जाए। एक बार इंस्टॉल होने के बाद, आप इसका उपयोग क्लस्टर बनाने के लिए कर सकते हैं।
आप kubectl संस्करण का उपयोग करे जो आपके क्लस्टर के एक माइनर संस्करण के भीतर हो। उदाहरण के लिए, v1.35 क्लाइंट v1.34, v1.35 और v1.36 कण्ट्रोल प्लेन के साथ संवाद कर सकते हैं। kubectl के नवीनतम संस्करण का उपयोग करने से अप्रत्याशित मुद्दों से बचने में मदद मिलती है।
Linux पर kubectl संस्थापित करने के लिए निम्नलिखित विधियाँ मौजूद हैं:
कमांड से नवीनतम रिलीज डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
एक विशिष्ट संस्करण डाउनलोड करने के लिए, कमांड के $(curl -L -s https://dl.k8s.io/release/stable.txt) हिस्से को विशिष्ट संस्करण से बदलें।
उदाहरण के लिए, लिनक्स पर 1.35.0 संस्करण डाउनलोड करने के लिए, टाइप करें:
curl -LO https://dl.k8s.io/release/v1.35.0/bin/linux/amd64/kubectl
बाइनरी को मान्य करें (वैकल्पिक)
kubectl चेकसम फाइल डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
चेकसम फ़ाइल से kubectl बाइनरी को मान्य करें:
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
यदि मान्य है, तो आउटपुट है:
kubectl: OK
अगर चेक फेल हो जाता है, तो sha256 nonzero स्थिति के साथ बाहर निकलता है और इस आउटपुट के समान प्रिंट करता है:
kubectl: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
kubectl इंस्टॉल करें
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
यदि आपके पास टारगेट सिस्टम पर रुट एक्सेस नहीं है, आप तब भी kubectl को ~/.local/bin डायरेक्टरी में इंस्टॉल कर सकते हैं:
chmod +x kubectl
mkdir -p ~/.local/bin/kubectl
mv ./kubectl ~/.local/bin/kubectl
# and then add ~/.local/bin/kubectl to $PATH
यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:
kubectl version --client
apt पैकेज इंडेक्स को अपडेट करे और कुबेरनेट्स apt रिपॉजिटरी का उपयोग करने के लिए आवश्यक पैकेज इंस्टॉल करें:
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
गूगल क्लाउड पब्लिक साइनिंग कुंजी (key) डाउनलोड करें:
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
कुबेरनेट्स apt रिपॉजिटरी को जोड़े:
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
नए रिपॉजिटरी के साथ apt पैकेज इंडेक्स अपडेट करें और kubectl इंस्टॉल करें:
sudo apt-get update
sudo apt-get install -y kubectl
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
yum install -y kubectl
यदि आप Ubuntu या किसी अन्य Linux डिस्ट्रीब्यूशन पर हैं जो snap पैकेज मैनेजर को सपोर्ट करता है, तो kubectl snap एप्लिकेशन के रूप में उपलब्ध है।
snap install kubectl --classic
kubectl version --client
यदि आप Linux पर Homebrew पैकेज मैनेजर का उपयोग कर रहे हैं, तो kubectl इंस्टालेशन के लिए उपलब्ध है।
brew install kubectl
kubectl version --client
kubectl को कुबेरनेट्स क्लस्टर को खोजने और एक्सेस करने के लिए, उसे
क्यूबकॉन्फिग फाइल(kubeconfig) की आवश्यकता होती है,
जो स्वचालित रूप से तब बनता है जब आप
kube-up.sh का उपयोग करके क्लस्टर बनाते हैं
या मिनीक्यूब क्लस्टर को सफलतापूर्वक डिप्लॉय करते हैं।
डिफ़ॉल्ट रूप से, kubectl कॉन्फ़िगरेशन ~/.kube/config पर स्थित होता है।
जाँच करें कि क्लस्टर स्टेट प्राप्त करके kubectl को ठीक से कॉन्फ़िगर किया गया है:
kubectl cluster-info
यदि आपको एक URL प्रतिक्रिया दिखती हैं, तो kubectl आपके क्लस्टर तक पहुँचने के लिए सही ढंग से कॉन्फ़िगर हुआ है।
यदि आपको निम्नलिखित संदेश दिखाई देता है, तो kubectl ठीक से कॉन्फ़िगर नहीं हुआ है या कुबेरनेट्स क्लस्टर से कनेक्ट करने में सक्षम नहीं है।
The connection to the server <server-name:port> was refused - did you specify the right host or port?
उदाहरण के लिए, यदि आप अपने लैपटॉप (स्थानीय रूप से) पर कुबेरनेट्स क्लस्टर चलाना चाहते हैं, तो आपको पहले मिनीक्यूब (minikube) जैसे टूल को इंस्टॉल करना होगा और ऊपर बताए गए कमांड को फिर से चलाना होगा।
यदि kubectl cluster-info URL प्रतिक्रिया देता है, लेकिन आप अपने क्लस्टर को एक्सेस नहीं कर पा रहें हैं, तो यह जाँचने के लिए कि क्या यह ठीक से कॉन्फ़िगर किया गया है, इस कमांड का उपयोग करें:
kubectl cluster-info dump
kubectl Bash और Zsh के लिए ऑटोकम्प्लेशन का सपोर्ट प्रदान करता है, जो आपका काफी समय बचा सकता है।
नीचे Bash और Zsh के लिए ऑटोकम्प्लेशन स्थापित करने की प्रक्रियाएँ हैं।
Bash के लिए kubectl समापन स्क्रिप्ट kubectl completion bash कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में समापन स्क्रिप्ट को सोर्स करने से kubectl ऑटोकम्पलीशन सक्षम हो जाती है।
हालाँकि, समापन की स्क्रिप्ट bash-completion पर निर्भर हैं जिसका अर्थ है कि आपको पहले इस सॉफ़्टवेयर को इंस्टॉल करना होगा (आप type _init_completion चलाकर परीक्षण कर सकते हैं कि आपने पहले से bash-completion इंस्टॉल की है या नहीं)।
कई पैकेज मैनेजर द्वारा bash-completion प्रदान की जाती है (यहाँ देखें)। आप इसे apt-get install bash-completion या yum install bash-completion आदि के साथ इंस्टॉल कर सकते हैं।
यह कमांड /usr/share/bash-completion/bash_completion उत्त्पन्न करता है, जो bash-completion की मुख्य स्क्रिप्ट है। आपके पैकेज मैनेजर के आधार पर, आपको इस फाइल को अपनी ~/.bashrc फाइल में मैन्युअल रूप से सोर्स करना होगा।
यह पता लगाने के लिए, अपना शेल पुनः लोड करें और type _init_completion रन करे। यदि कमांड सफल होता है, तो आप पहले से ही तैयार हैं, अन्यथा अपनी ~/.bashrc फ़ाइल में निम्नलिखित जोड़ें:
source /usr/share/bash-completion/bash_completion
अपना शेल पुनः लोड करें और type _init_completion टाइप करके सत्यापित करें कि बैश-कम्पलीशन सही ढंग से इंस्टॉल है।
अब आपको यह सुनिश्चित करने की आवश्यकता है कि kubectl समापन स्क्रिप्ट आपके सभी शेल सत्रों (sourced) में प्राप्त हो जाए। आप ऐसा दो तरीकों से कर सकते हैं:
अपनी ~/.bashrc फ़ाइल में समापन स्क्रिप्ट सॉर्स करें:
echo 'source <(kubectl completion bash)' >>~/.bashr
समापन स्क्रिप्ट को /etc/bash_completion.d डायरेक्टरी में जोड़ें:
bash kubectl completion bash >/etc/bash_completion.d/kubectl
यदि आप के पास kubectl के लिए एक अन्य नाम (alias) है, तो आप उस अन्य नाम के साथ काम करने के लिए शेल समापन को बढ़ा सकते हैं:
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc
/etc/bash_completion.d में सोर्स करता है।दोनों दृष्टिकोण बराबर हैं। आपके शेल को पुनः लोड करने के बाद, Kubectl ऑटोकम्पलीशन कार्य करना शुरू कर देगा।
Zsh के लिए kubectl कम्पलीशन स्क्रिप्ट kubectl completion zsh कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में कम्पलीशन स्क्रिप्ट को सोर्स करने से kubectl ऑटो-कम्पलीशन सक्षम हो जाती है।
अपने सभी शेल सत्रों में ऐसा करने के लिए, निम्नलिखित को अपनी ~/.zshrc फ़ाइल में जोड़ें:
source <(kubectl completion zsh)
यदि आपके पास kubectl के लिए एक उपनाम है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं:
echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc
अपने शेल को पुनः लोड करने के बाद, kubectl ऑटो-कम्पलीशन कार्य करना चाहिए।
यदि आपको कोई त्रुटि मिलती है जैसे complete:13: command not found: compdef, तो अपनी ~/.zshrc फ़ाइल की शुरुआत में निम्नलिखित जोड़ें:
autoload -Uz compinit
compinit
kubectl convert प्लगइन इंस्टॉल करेंकुबेरनेट्स कमांड-लाइन टूल kubectl के लिए एक प्लगइन, जो आपको विभिन्न API संस्करण के बीच मैनिफ़ेस्ट को बदलने करने की अनुमति देता है।
यह विशेष रूप से नए कुबेरनेट्स रिलीज के साथ एक गैर-बहिष्कृत API संस्करण में मैनिफेस्ट को माइग्रेट करने में सहायक हो सकता है।
अधिक जानकारी के लिए, गैर पदावनत एपिस में विस्थापित करें पर जाएं।
कमांड से नवीनतम रिलीज डाउनलोड करें:
curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert
बाइनरी को मान्य करें (वैकल्पिक)
kubectl-convert चेकसम फ़ाइल डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256"
चेकसम फ़ाइल से kubectl-convert बाइनरी को मान्य करें:
echo "$(<kubectl-convert.sha256) kubectl-convert" | sha256sum --check
यदि मान्य है, तो आउटपुट है:
kubectl-convert: OK
अगर चेक फेल हो जाता है, तो sha256 nonzero स्थिति के साथ बाहर निकलता है और इस आउटपुट के समान प्रिंट करता है:
kubectl-convert: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
kubectl-convert इंस्टॉल करें
sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert
सत्यापित करें कि प्लगइन सफलतापूर्वक इंस्टॉल है
kubectl convert --help
यदि आपको कोई त्रुटि नहीं दिखाई देती है, तो इसका मतलब है कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है।
आप kubectl संस्करण का उपयोग करे जो आपके क्लस्टर के एक माइनर संस्करण भीतर हो। उदाहरण के लिए, v1.35 क्लाइंट v1.34, v1.35 और v1.36 कण्ट्रोल प्लेन के साथ कम्युनिकेट कर सकते हैं। kubectl के नए संस्करण का उपयोग करने से समस्या से बचत हो सकती है।
macOS पर kubectl संस्थापित करने के लिए निम्नलिखित विधियाँ मौजूद हैं:
नवीनतम रिलीज़ डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"
एक विशिष्ट संस्करण डाउनलोड करने के लिए, कमांड के इस हिस्से $(curl -L -s https://dl.k8s.io/release/stable.txt) को विशिष्ट संस्करण से बदलें।
उदाहरण के लिए, Intel macOS पर 1.35.0 संस्करण डाउनलोड करने के लिए, टाइप करें:
curl -LO "https://dl.k8s.io/release/v1.35.0/bin/darwin/amd64/kubectl"
और Apple Silicon macOS के लिए, टाइप करें:
curl -LO "https://dl.k8s.io/release/v1.35.0/bin/darwin/arm64/kubectl"
बाइनरी को मान्य करें (वैकल्पिक))
kubectl चेकसम फाइल डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256"
चेकसम फ़ाइल से kubectl बाइनरी को मान्य करें:
echo "$(<kubectl.sha256) kubectl" | shasum -a 256 --check
यदि मान्य है, तो आउटपुट है:
kubectl: OK
अगर चेक फेल हो जाता है, तो shasum nonzero स्थिति के साथ बाहर निकलता है और इस आउटपुट के समान प्रिंट करता है:
kubectl: FAILED
shasum: WARNING: 1 computed checksum did NOT match
kubectl बाइनरी को एक्सेक्यूट करने योग्य बनायें।
chmod +x ./kubectl
kubectl बाइनरी को अपने सिस्टम PATH के फ़ाइल स्थान पर ले जाएँ।
sudo mv ./kubectl /usr/local/bin/kubectl
sudo chown root: /usr/local/bin/kubectl
/usr/local/bin आपके पाथ एनवायरनमेंट वेरिएबल में है।यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:
kubectl version --client
यदि आप macOS पर हैं और Homebrew पैकेज मैनेजर का उपयोग कर रहे हैं, आप Homebrew के साथ kubectl इंस्टॉल कर सकते हैं।
इंस्टालेशन कमांड रन करें:
brew install kubectl
या
brew install kubernetes-cli
यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:
kubectl version --client
यदि आप macOS पर हैं और Macports पैकेज मैनेजर का उपयोग कर रहे हैं, आप Macports के साथ kubectl इंस्टॉल कर सकते हैं।
इंस्टालेशन कमांड रन करें:
sudo port selfupdate
sudo port install kubectl
यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:
kubectl version --client
kubectl को कुबेरनेट्स क्लस्टर को खोजने और एक्सेस करने के लिए, उसे
क्यूबकॉन्फिग फाइल(kubeconfig) की आवश्यकता होती है,
जो स्वचालित रूप से तब बनता है जब आप
kube-up.sh का उपयोग करके क्लस्टर बनाते हैं
या मिनीक्यूब क्लस्टर को सफलतापूर्वक डिप्लॉय करते हैं।
डिफ़ॉल्ट रूप से, kubectl कॉन्फ़िगरेशन ~/.kube/config पर स्थित होता है।
जाँच करें कि क्लस्टर स्टेट प्राप्त करके kubectl को ठीक से कॉन्फ़िगर किया गया है:
kubectl cluster-info
यदि आपको एक URL प्रतिक्रिया दिखती हैं, तो kubectl आपके क्लस्टर तक पहुँचने के लिए सही ढंग से कॉन्फ़िगर हुआ है।
यदि आपको निम्नलिखित संदेश दिखाई देता है, तो kubectl ठीक से कॉन्फ़िगर नहीं हुआ है या कुबेरनेट्स क्लस्टर से कनेक्ट करने में सक्षम नहीं है।
The connection to the server <server-name:port> was refused - did you specify the right host or port?
उदाहरण के लिए, यदि आप अपने लैपटॉप (स्थानीय रूप से) पर कुबेरनेट्स क्लस्टर चलाना चाहते हैं, तो आपको पहले मिनीक्यूब (minikube) जैसे टूल को इंस्टॉल करना होगा और ऊपर बताए गए कमांड को फिर से चलाना होगा।
यदि kubectl cluster-info URL प्रतिक्रिया देता है, लेकिन आप अपने क्लस्टर को एक्सेस नहीं कर पा रहें हैं, तो यह जाँचने के लिए कि क्या यह ठीक से कॉन्फ़िगर किया गया है, इस कमांड का उपयोग करें:
kubectl cluster-info dump
kubectl Bash और Zsh के लिए ऑटोकम्प्लेशन का सपोर्ट प्रदान करता है, जो आपका काफी समय बचा सकता है।
नीचे Bash और Zsh के लिए ऑटोकम्प्लेशन स्थापित करने की प्रक्रियाएँ हैं।
Bash के लिए kubectl समापन स्क्रिप्ट kubectl completion bash कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में समापन स्क्रिप्ट को सोर्स करने से kubectl ऑटोकम्पलीशन सक्षम हो जाती है।```
हालाँकि, समापन की स्क्रिप्ट bash-completion पर निर्भर हैं जिसका अर्थ है कि आपको पहले इस सॉफ़्टवेयर को इंस्टॉल करना होगा।
निम्नलिखित निर्देश मानते हैं कि आप बैश 4.1+ का उपयोग करते हैं। आप अपने बैश के संस्करण को यह चलाकर देख सकते हैं:
echo $BASH_VERSION
यदि यह बहुत पुराना है, तो आप Homebrew का उपयोग करके इसे इनस्टॉल/अपग्रेड कर सकते हैं:
brew install bash
अपने शेल को पुनः लोड करें और सत्यापित करें कि इच्छित संस्करण का उपयोग किया जा रहा है:
echo $BASH_VERSION $SHELL
Homebrew आमतौर पर इसे /usr/local/bin/bash पर इनस्टॉल करता है।
आप type_init_completion से सत्यापित कर सकते हैं कि क्या आपके पास bash-completion v2 पहले से इनस्टॉल है। यदि नहीं, तो आप इसे Homebrew से इनस्टॉल कर सकते हैं
brew install bash-completion@2
जैसा कि इस कमांड के आउटपुट में बताया गया है, अपनी ~/.bash_profile फ़ाइल में निम्नलिखित जोड़ें:
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
अपने शेल को पुनः लोड करें और type_init_completion से सत्यापित करें कि bash-completion v2 सही ढंग से इनस्टॉल है।
अब आपको यह सुनिश्चित करने की आवश्यकता है कि kubectl समापन स्क्रिप्ट आपके सभी शेल सत्रों (sourced) में प्राप्त हो जाए। इसे हासिल करने के कई तरीके हैं:
अपने कम्पलीशन स्क्रिप्ट को ~/.bash_profile में सोर्स करें:
echo 'source <(kubectl completion bash)' >>~/.bash_profile
कम्पलीशन स्क्रिप्ट को /usr/local/etc/bash_completion.d डायरेक्टरी में जोड़ें:
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
यदि आपके पास kubectl के लिए एक नाम (alias) है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं:
echo 'alias k=kubectl' >>~/.bash_profile
echo 'complete -F __start_kubectl k' >>~/.bash_profile
यदि आपने Homebrew के साथ kubectl इनस्टॉल किया है (जैसा कि यहां बताया गया है), तो kubectl कम्पलीशन स्क्रिप्ट पहले से ही /usr/local/etc/bash_completion.d/kubectl में होनी चाहिए। ऐसे में आपको कुछ भी करने की जरूरत नहीं है।
BASH_COMPLETION_COMPAT_DIR डायरेक्टरी में सोर्स कर देता है। इसलिए आखरी दो तरीके काम करते हैं।Zsh के लिए kubectl कम्पलीशन स्क्रिप्ट kubectl completion zsh कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में कम्पलीशन स्क्रिप्ट को सोर्स करने से kubectl ऑटो-कम्पलीशन सक्षम हो जाती है।
अपने सभी शेल सत्रों में ऐसा करने के लिए, निम्नलिखित को अपनी ~/.zshrc फ़ाइल में जोड़ें:
source <(kubectl completion zsh)
यदि आपके पास kubectl के लिए एक उपनाम है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं:
echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc
अपने शेल को पुनः लोड करने के बाद, kubectl ऑटो-कम्पलीशन कार्य करना चाहिए।
यदि आपको कोई त्रुटि मिलती है जैसे complete:13: command not found: compdef, तो अपनी ~/.zshrc फ़ाइल की शुरुआत में निम्नलिखित जोड़ें:
autoload -Uz compinit
compinit
kubectl convert प्लगइन इंस्टॉल करेंकुबेरनेट्स कमांड-लाइन टूल kubectl के लिए एक प्लगइन, जो आपको विभिन्न API संस्करण के बीच मैनिफ़ेस्ट को बदलने करने की अनुमति देता है।
यह विशेष रूप से नए कुबेरनेट्स रिलीज के साथ एक गैर-बहिष्कृत API संस्करण में मैनिफेस्ट को माइग्रेट करने में सहायक हो सकता है।
अधिक जानकारी के लिए, गैर पदावनत एपिस में विस्थापित करें पर जाएं।
इस कमांड से नवीनतम रिलीज डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert"
बाइनरी को मान्य करें (वैकल्पिक)
kubectl-convert चेकसम फ़ाइल डाउनलोड करें:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256"
चेकसम फ़ाइल से kubectl-convert बाइनरी को मान्य करें:
echo "$(<kubectl-convert.sha256) kubectl-convert" | shasum -a 256 --check
यदि मान्य है, तो आउटपुट है:
kubectl-convert: OK
अगर चेक फेल हो जाता है, तो sha256 nonzero स्थिति के साथ बाहर निकलता है और इस आउटपुट के समान प्रिंट करता है:
kubectl-convert: FAILED
shasum: WARNING: 1 computed checksum did NOT match
Kubectl-कन्वर्ट बाइनरी को एक्सेक्यूट करने योग्य बनाएं
chmod +x ./kubectl-convert
kubectl-convert binary बाइनरी को अपने सिस्टम PATH के फ़ाइल स्थान पर ले जाएँ।
sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
sudo chown root: /usr/local/bin/kubectl-convert
/usr/local/bin आपके पाथ एनवायरनमेंट वेरिएबल में है।सत्यापित करें कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है
kubectl convert --help
यदि आपको कोई त्रुटि नहीं दिखाई देती है, तो इसका मतलब है कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है।
आप kubectl संस्करण का उपयोग करे जो आपके क्लस्टर के एक माइनर संस्करण भीतर हो। उदाहरण के लिए, v1.35 क्लाइंट v1.34, v1.35 और v1.36 कण्ट्रोल प्लेन के साथ कम्युनिकेट कर सकते हैं। kubectl के नए संस्करण का उपयोग करने से समस्या से बचत हो सकती है।
Windows पर kubectl संस्थापित करने के लिए निम्नलिखित विधियाँ मौजूद हैं:
latest release 1.35.0 डाउनलोड करें।
या यदि आपके पास curl है, तो इस कमांड का उपयोग करें:
curl -LO https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl.exe
बाइनरी को मान्य करें (वैकल्पिक)
kubectl चेकसम फाइल डाउनलोड करें:
curl -LO https://dl.k8s.io/v1.35.0/bin/windows/amd64/kubectl.exe.sha256
चेकसम फ़ाइल से kubectl बाइनरी को मान्य करें:
मैन्युअल रूप से कमांड प्रॉम्प्ट का उपयोग करके CertUtil के आउटपुट की तुलना डाउनलोडेड चेकसम फ़ाइल से करें:
CertUtil -hashfile kubectl.exe SHA256
type kubectl.exe.sha256
True या False परिणाम प्राप्त करने के लिए -eq ऑपरेटर का उपयोग करके सत्यापन को ऑटोमेट करने के लिए powershell का उपयोग करें:
$(Get-FileHash -Algorithm SHA256 .\kubectl.exe).Hash -eq $(Get-Content .\kubectl.exe.sha256)
अपने PATH में बाइनरी जोड़ें।
यह सुनिश्चित करने के लिए परीक्षण करें कि kubectl संस्करण डाउनलोड के समान है:
kubectl version --client
kubectl का अपना संस्करण PATH में जोड़ता है।
यदि आपने पहले Docker Desktop स्थापित किया है, तो आपको Docker Desktop इंस्टॉलर द्वारा जोड़े गए एक PATH से पहले अपनी PATH प्रविष्टि डालने की आवश्यकता हो सकती है या Docker Desktop के kubectl को हटा दें।Windows पर kubectl इंस्टॉल करने के लिए आप या तो Chocolatey पैकेज मैनेजर अथवा Scoop कमांड-लाइन इंस्टॉलर का उपयोग कर सकते हैं।
choco install kubernetes-cli
scoop install kubectl
यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:
kubectl version --client
अपनी होम डायरेक्टरी पर जाएं:
# यदि आप cmd.exe का प्रयोग कर रहे हैं, तो: cd %USERPROFILE%
cd ~
.kube डायरेक्टरी बनाएं:
mkdir .kube
आपके द्वारा अभी बनाई गई .kube डायरेक्टरी में जाएं:
cd .kube
दूरस्थ कुबेरनेट्स क्लस्टर का उपयोग करने के लिए kubectl को कॉन्फ़िगर करें:
New-Item config -type file
kubectl को कुबेरनेट्स क्लस्टर को खोजने और एक्सेस करने के लिए, उसे
क्यूबकॉन्फिग फाइल(kubeconfig) की आवश्यकता होती है,
जो स्वचालित रूप से तब बनता है जब आप
kube-up.sh का उपयोग करके क्लस्टर बनाते हैं
या मिनीक्यूब क्लस्टर को सफलतापूर्वक डिप्लॉय करते हैं।
डिफ़ॉल्ट रूप से, kubectl कॉन्फ़िगरेशन ~/.kube/config पर स्थित होता है।
जाँच करें कि क्लस्टर स्टेट प्राप्त करके kubectl को ठीक से कॉन्फ़िगर किया गया है:
kubectl cluster-info
यदि आपको एक URL प्रतिक्रिया दिखती हैं, तो kubectl आपके क्लस्टर तक पहुँचने के लिए सही ढंग से कॉन्फ़िगर हुआ है।
यदि आपको निम्नलिखित संदेश दिखाई देता है, तो kubectl ठीक से कॉन्फ़िगर नहीं हुआ है या कुबेरनेट्स क्लस्टर से कनेक्ट करने में सक्षम नहीं है।
The connection to the server <server-name:port> was refused - did you specify the right host or port?
उदाहरण के लिए, यदि आप अपने लैपटॉप (स्थानीय रूप से) पर कुबेरनेट्स क्लस्टर चलाना चाहते हैं, तो आपको पहले मिनीक्यूब (minikube) जैसे टूल को इंस्टॉल करना होगा और ऊपर बताए गए कमांड को फिर से चलाना होगा।
यदि kubectl cluster-info URL प्रतिक्रिया देता है, लेकिन आप अपने क्लस्टर को एक्सेस नहीं कर पा रहें हैं, तो यह जाँचने के लिए कि क्या यह ठीक से कॉन्फ़िगर किया गया है, इस कमांड का उपयोग करें:
kubectl cluster-info dump
kubectl Bash और Zsh के लिए ऑटोकम्प्लेशन का सपोर्ट प्रदान करता है, जो आपको बहुत सारी टाइपिंग बचा सकता है।
नीचे Zsh के लिए ऑटोकम्प्लेशन स्थापित करने की प्रक्रियाएँ हैं, यदि आप इसे Windows पर चला रहे हैं।
Zsh के लिए kubectl कम्पलीशन स्क्रिप्ट kubectl completion zsh कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में कम्पलीशन स्क्रिप्ट को सोर्स करने से kubectl ऑटो-कम्पलीशन सक्षम हो जाती है।
अपने सभी शेल सत्रों में ऐसा करने के लिए, निम्नलिखित को अपनी ~/.zshrc फ़ाइल में जोड़ें:
source <(kubectl completion zsh)
यदि आपके पास kubectl के लिए एक उपनाम है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं:
echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc
अपने शेल को पुनः लोड करने के बाद, kubectl ऑटो-कम्पलीशन कार्य करना चाहिए।
यदि आपको कोई त्रुटि मिलती है जैसे complete:13: command not found: compdef, तो अपनी ~/.zshrc फ़ाइल की शुरुआत में निम्नलिखित जोड़ें:
autoload -Uz compinit
compinit
kubectl convert प्लगइनकुबेरनेट्स कमांड-लाइन टूल kubectl के लिए एक प्लगइन, जो आपको विभिन्न API संस्करण के बीच मैनिफ़ेस्ट को बदलने करने की अनुमति देता है।
यह विशेष रूप से नए कुबेरनेट्स रिलीज के साथ एक गैर-बहिष्कृत API संस्करण में मैनिफेस्ट को माइग्रेट करने में सहायक हो सकता है।
अधिक जानकारी के लिए, गैर पदावनत एपिस में विस्थापित करें पर जाएं।
इस कमांड से नवीनतम रिलीज डाउनलोड करें:
curl -LO https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl-convert.exe
बाइनरी को मान्य करें (वैकल्पिक)
kubectl-convert चेकसम फ़ाइल डाउनलोड करें:
curl -LO https://dl.k8s.io/v1.35.0/bin/windows/amd64/kubectl-convert.exe.sha256
चेकसम फ़ाइल से kubectl-convert बाइनरी को मान्य करें:
मैन्युअल रूप से कमांड प्रॉम्प्ट का उपयोग करके CertUtil के आउटपुट की तुलना डाउनलोड किये गये चेकसम फ़ाइल से करें:
CertUtil -hashfile kubectl-convert.exe SHA256
type kubectl-convert.exe.sha256
True या False परिणाम प्राप्त करने और -eq ऑपरेटर का उपयोग करके सत्यापन को ऑटोमेट करने के लिए Powershell का उपयोग करें:
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
अपने PATH में बाइनरी जोड़ें।
सत्यापित करें कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है।
kubectl convert --help
यदि आपको कोई त्रुटि नहीं दिखाई देती है, तो इसका मतलब है कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
आप पहले JSON या YAML फॉर्मेट में एक मैनिफेस्ट में Secret ऑब्जेक्ट को परिभाषित कर सकते हैं, और फिर उस ऑब्जेक्ट को बना सकते हैं। Secret रिसोर्स में दो मैप्स होते हैं: data और stringData। data फील्ड का उपयोग मनमाना डेटा स्टोर करने के लिए किया जाता है, जो base64 का उपयोग करके एनकोड किया जाता है। stringData फील्ड सुविधा के लिए प्रदान किया जाता है, और यह आपको समान डेटा को अनएनकोडेड स्ट्रिंग्स के रूप में प्रदान करने की अनुमति देता है। data और stringData की कुंजियों में अल्फ़ान्यूमेरिक वर्ण, -, _ या . होने चाहिए।
निम्नलिखित उदाहरण data फील्ड का उपयोग करके एक सीक्रेट में दो स्ट्रिंग्स स्टोर करता है।
स्ट्रिंग्स को base64 में कनवर्ट करें:
echo -n 'admin' | base64
echo -n '1f2d1e2e67df' | base64
base64 यूटिलिटी का उपयोग करते समय, उपयोगकर्ताओं को लंबी लाइनों को विभाजित करने के लिए -b विकल्प का उपयोग करने से बचना चाहिए। इसके विपरीत, Linux उपयोगकर्ताओं को base64 कमांड में -w 0 विकल्प जोड़ना चाहिए या यदि -w विकल्प उपलब्ध नहीं है तो base64 | tr -d '\n' पाइपलाइन का उपयोग करना चाहिए।आउटपुट इस तरह का होता है:
YWRtaW4=
MWYyZDFlMmU2N2Rm
मैनिफेस्ट बनाएं:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
ध्यान दें कि एक सीक्रेट ऑब्जेक्ट का नाम एक मान्य DNS सबडोमेन नाम होना चाहिए।
kubectl apply का उपयोग करके सीक्रेट बनाएं:
kubectl apply -f ./secret.yaml
आउटपुट इस तरह का होता है:
secret/mysecret created
यह सत्यापित करने के लिए कि सीक्रेट बनाया गया था और सीक्रेट डेटा को डिकोड करने के लिए, kubectl का उपयोग करके सीक्रेट्स का प्रबंधन देखें।
कुछ परिदृश्यों के लिए, आप stringData फील्ड का उपयोग करना चाह सकते हैं। यह फील्ड आपको सीक्रेट में सीधे एक नॉन-base64 एनकोडेड स्ट्रिंग डालने की अनुमति देता है, और जब सीक्रेट बनाया या अपडेट किया जाता है तो स्ट्रिंग आपके लिए एनकोड की जाएगी।
इसका एक व्यावहारिक उदाहरण यह हो सकता है जहां आप एक एप्लिकेशन डिप्लॉय कर रहे हैं जो कॉन्फ़िगरेशन फाइल को स्टोर करने के लिए एक सीक्रेट का उपयोग करता है, और आप अपनी डिप्लॉयमेंट प्रक्रिया के दौरान उस कॉन्फ़िगरेशन फाइल के कुछ हिस्सों को पॉप्युलेट करना चाहते हैं।
उदाहरण के लिए, यदि आपका एप्लिकेशन निम्नलिखित कॉन्फ़िगरेशन फाइल का उपयोग करता है:
apiUrl: "https://my.api.com/api/v1"
username: "<user>"
password: "<password>"
आप इसे निम्नलिखित परिभाषा का उपयोग करके एक सीक्रेट में स्टोर कर सकते हैं:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
stringData:
config.yaml: |
apiUrl: "https://my.api.com/api/v1"
username: <user>
password: <password>
stringData फील्ड सर्वर-साइड एप्लाई के साथ अच्छी तरह से काम नहीं करता है।जब आप सीक्रेट डेटा प्राप्त करते हैं, तो कमांड एनकोडेड वैल्यू वापस करता है, न कि वे प्लेनटेक्स्ट वैल्यू जो आपने stringData में प्रदान किए थे।
उदाहरण के लिए, यदि आप निम्नलिखित कमांड चलाते हैं:
kubectl get secret mysecret -o yaml
आउटपुट इस तरह का होता है:
apiVersion: v1
data:
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:40:59Z
name: mysecret
namespace: default
resourceVersion: "7225"
uid: c280ad2e-e916-11e8-98f2-025000000001
type: Opaque
data और stringData दोनों निर्दिष्ट करेंयदि आप एक फील्ड को data और stringData दोनों में निर्दिष्ट करते हैं, तो stringData से वैल्यू का उपयोग किया जाता है।
उदाहरण के लिए, यदि आप निम्नलिखित सीक्रेट को परिभाषित करते हैं:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
stringData:
username: administrator
stringData फील्ड सर्वर-साइड एप्लाई के साथ अच्छी तरह से काम नहीं करता है।Secret ऑब्जेक्ट इस प्रकार बनाया जाता है:
apiVersion: v1
data:
username: YWRtaW5pc3RyYXRvcg==
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:46:46Z
name: mysecret
namespace: default
resourceVersion: "7579"
uid: 91460ecb-e917-11e8-98f2-025000000001
type: Opaque
YWRtaW5pc3RyYXRvcg== डिकोड होकर administrator बनता है।
मैनिफेस्ट का उपयोग करके बनाए गए सीक्रेट में डेटा को संपादित करने के लिए, अपने मैनिफेस्ट में data या stringData फील्ड को संशोधित करें और फाइल को अपने क्लस्टर में लागू करें। आप एक मौजूदा Secret ऑब्जेक्ट को संपादित कर सकते हैं जब तक कि वह अपरिवर्तनीय नहीं है।
उदाहरण के लिए, यदि आप पिछले उदाहरण से पासवर्ड को birdsarentreal में बदलना चाहते हैं, तो निम्नलिखित करें:
नई पासवर्ड स्ट्रिंग को एनकोड करें:
echo -n 'birdsarentreal' | base64
आउटपुट इस तरह का होता है:
YmlyZHNhcmVudHJlYWw=
अपनी नई पासवर्ड स्ट्रिंग के साथ data फील्ड को अपडेट करें:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: YmlyZHNhcmVudHJlYWw=
मैनिफेस्ट को अपने क्लस्टर में लागू करें:
kubectl apply -f ./secret.yaml
आउटपुट इस तरह का होता है:
secret/mysecret configured
कुबेरनेट्स मौजूदा Secret ऑब्जेक्ट को अपडेट करता है। विस्तार से, kubectl टूल नोटिस करता है कि समान नाम का एक मौजूदा Secret ऑब्जेक्ट है। kubectl मौजूदा ऑब्जेक्ट को प्राप्त करता है, उसमें परिवर्तनों की योजना बनाता है, और बदले हुए Secret ऑब्जेक्ट को आपके क्लस्टर कंट्रोल प्लेन को सबमिट करता है।
यदि आपने इसके बजाय kubectl apply --server-side निर्दिष्ट किया है, तो kubectl सर्वर साइड एप्लाई का उपयोग करता है।
आपके द्वारा बनाए गए सीक्रेट को हटाने के लिए:
kubectl delete secret mysecret
यह पृष्ठ दिखाता है कि कुबेरनेट्स पॉड में किसी कंटेनर के लिए निर्भर एनवायरनमेंट वेरिएबल्स कैसे परिभाषित करें।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
जब आप एक पॉड बनाते हैं, तो आप उसमें चलने वाले कंटेनरों के लिए निर्भर एनवायरनमेंट वेरिएबल्स सेट कर सकते हैं। निर्भर एनवायरनमेंट वेरिएबल्स सेट करने के लिए, आप कॉन्फ़िगरेशन फ़ाइल में env की value में $(VAR_NAME) का उपयोग कर सकते हैं।
इस अभ्यास में, आप एक ऐसा पॉड बनाएंगे जो एक कंटेनर चलाता है।
पॉड के लिए कॉन्फ़िगरेशन फ़ाइल में एक निर्भर एनवायरनमेंट वेरिएबल्स परिभाषित किया गया है, जिसका सामान्य उपयोग निर्धारित किया गया है।
पॉड के लिए कॉन्फ़िगरेशन मैनिफेस्ट इस प्रकार है:
apiVersion: v1
kind: Pod
metadata:
name: dependent-envars-demo
spec:
containers:
- name: dependent-envars-demo
args:
- while true; do echo -en '\n'; printf UNCHANGED_REFERENCE=$UNCHANGED_REFERENCE'\n'; printf SERVICE_ADDRESS=$SERVICE_ADDRESS'\n';printf ESCAPED_REFERENCE=$ESCAPED_REFERENCE'\n'; sleep 30; done;
command:
- sh
- -c
image: busybox:1.28
env:
- name: SERVICE_PORT
value: "80"
- name: SERVICE_IP
value: "172.17.0.1"
- name: UNCHANGED_REFERENCE
value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
- name: PROTOCOL
value: "https"
- name: SERVICE_ADDRESS
value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
- name: ESCAPED_REFERENCE
value: "$$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
उस मैनिफेस्ट के आधार पर एक पॉड बनाएँ:
kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml
pod/dependent-envars-demo created
चल रहे पॉड्स की सूची देखें:
kubectl get pods dependent-envars-demo
NAME READY STATUS RESTARTS AGE
dependent-envars-demo 1/1 Running 0 9s
अपने पॉड में चल रहे कंटेनर के लॉग्स देखें:
kubectl logs pod/dependent-envars-demo
UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
SERVICE_ADDRESS=https://172.17.0.1:80
ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
जैसा कि ऊपर दिखाया गया है, आपने SERVICE_ADDRESS के लिए एक सही डिपेंडेंसी रेफरेंस,
UNCHANGED_REFERENCE के लिए एक गलत डिपेंडेंसी रेफरेंस, और ESCAPED_REFERENCE के लिए एक स्किप किया गया रेफरेंस परिभाषित किया है।
जब कोई एनवायरनमेंट वेरिएबल पहले से परिभाषित होता है और उसका रेफरेंस दिया जाता है,
तो वह रेफरेंस सही तरीके से हल हो सकता है, जैसा कि SERVICE_ADDRESS के मामले में हुआ।
ध्यान दें कि env सूची में क्रम महत्वपूर्ण होता है।
अगर कोई वेरिएबल सूची में नीचे परिभाषित है, तो उसे परिभाषित नहीं माना जाता।
इसी कारण से UNCHANGED_REFERENCE $(PROTOCOL) को हल करने में विफल रहता है।
जब कोई एनवायरनमेंट वेरिएबल परिभाषित नहीं होता या उसमें कुछ वेरिएबल्स ही शामिल होते हैं,
तो वह वेरिएबल एक सामान्य स्ट्रिंग की तरह माना जाता है, जैसे कि UNCHANGED_REFERENCE।
ध्यान दें कि सामान्यतः गलत तरीके से पार्स किए गए एनवायरनमेंट वेरिएबल्स कंटेनर को शुरू होने से नहीं रोकते।
$(VAR_NAME) सिंटैक्स को डबल $, जैसे $$(VAR_NAME) से एस्केप किया जा सकता है।
एस्केप किए गए रेफरेंस कभी भी विस्तारित नहीं होते, चाहे संबंधित वेरिएबल परिभाषित हो या नहीं।
यह ESCAPED_REFERENCE उदाहरण में देखा जा सकता है।
kubectl Secrets और ConfigMaps का प्रबंधन करने के लिए Kustomize object management tool का उपयोग करने का समर्थन करता है। आप Kustomize का उपयोग करके एक resource generator बनाते हैं, जो
एक Secret उत्पन्न करता है जिसे आप kubectl का उपयोग करके API server पर apply कर सकते हैं।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
आप एक secretGenerator को परिभाषित करके एक Secret उत्पन्न कर सकते हैं
kustomization.yaml file में जो अन्य मौजूदा files, .env files, या
literal values को reference करता है। उदाहरण के लिए, निम्नलिखित निर्देश username admin और password 1f2d1e2e67df के लिए एक kustomization
file बनाते हैं।
stringData फ़ील्ड server-side apply के साथ अच्छी तरह से काम नहीं करता है।
secretGenerator:
- name: database-creds
literals:
- username=admin
- password=1f2d1e2e67df
क्रेडेंशियल्स को फ़ाइलों में स्टोर करें। फ़ाइल नाम secret की keys हैं:
echo -n 'admin' > ./username.txt
echo -n '1f2d1e2e67df' > ./password.txt
-n flag यह सुनिश्चित करता है कि आपकी फ़ाइलों के अंत में कोई newline वर्ण नहीं है।
kustomization.yaml file बनाएं:
secretGenerator:
- name: database-creds
files:
- username.txt
- password.txt
आप kustomization.yaml file में secretGenerator को भी परिभाषित कर सकते हैं
.env files प्रदान करके। उदाहरण के लिए, निम्नलिखित kustomization.yaml file
एक .env.secret file से डेटा pull करती है:
secretGenerator:
- name: db-user-pass
envs:
- .env.secret
सभी मामलों में, आपको values को base64 में encode करने की आवश्यकता नहीं है। YAML
file का नाम अवश्य kustomization.yaml या kustomization.yml होना चाहिए।
Secret बनाने के लिए, उस directory को apply करें जिसमें kustomization file है:
kubectl apply -k <directory-path>
आउटपुट इस प्रकार है:
secret/database-creds-5hdh7hhgfk created
जब एक Secret उत्पन्न होता है, तो Secret का नाम Secret डेटा को hash करके और hash value को नाम में append करके बनाया जाता है। यह सुनिश्चित करता है कि डेटा को modify किए जाने पर हर बार एक नया Secret उत्पन्न होता है।
Secret बनाया गया था या नहीं, इसे सत्यापित करने और Secret डेटा को डिकोड करने के लिए,
kubectl get -k <directory-path> -o jsonpath='{.data}'
आउटपुट इस प्रकार है:
{ "password": "MWYyZDFlMmU2N2Rm", "username": "YWRtaW4=" }
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
आउटपुट इस प्रकार है:
1f2d1e2e67df
अधिक जानकारी के लिए, देखें Managing Secrets using kubectl और Declarative Management of Kubernetes Objects Using Kustomize.
अपनी kustomization.yaml file में, डेटा को संशोधित करें, जैसे password।
उस directory को apply करें जिसमें kustomization file है:
kubectl apply -k <directory-path>
आउटपुट इस प्रकार है:
secret/db-user-pass-6f24b56cc8 created
संपादित Secret एक नए Secret object के रूप में बनाया जाता है, मौजूदा
Secret object को अपडेट करने के बजाय। आपको अपने Pods में Secret के references को अपडेट करने की आवश्यकता हो सकती है।
एक Secret को हटाने के लिए, kubectl का उपयोग करें:
kubectl delete secret db-user-pass
यह पेज दिखाता है कि कुबेरनेटेस API तक पहुंचने के लिए HTTP प्रॉक्सी का उपयोग कैसे करें।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
संस्करण की जांच करने के लिए, लिखें kubectl version.
यदि आपके क्लस्टर में पहले से कोई एप्लिकेशन नहीं चल रहा है, तो इस कमांड को दर्ज करके एक Hello world एप्लिकेशन शुरू करें:
kubectl create deployment hello-app --image=gcr.io/google-samples/hello-app:2.0 --port=8080
यह कमांड कुबेरनेटेस API सर्वर के लिए एक प्रॉक्सी शुरू करता है:
kubectl proxy --port=8080
जब प्रॉक्सी सर्वर चल रहा हो, तो आप curl, wget, या ब्राउज़र का उपयोग करके API का अन्वेषण कर सकते हैं।
API संस्करण प्राप्त करें:
curl http://localhost:8080/api/
आउटपुट इस तरह दिखना चाहिए:
{
"kind": "APIVersions",
"versions": [
"v1"
],
"serverAddressByClientCIDRs": [
{
"clientCIDR": "0.0.0.0/0",
"serverAddress": "10.0.2.15:8443"
}
]
}
पॉड्स की सूची प्राप्त करें:
curl http://localhost:8080/api/v1/namespaces/default/pods
आउटपुट इस तरह दिखना चाहिए:
{
"kind": "PodList",
"apiVersion": "v1",
"metadata": {
"resourceVersion": "33074"
},
"items": [
{
"metadata": {
"name": "kubernetes-bootcamp-2321272333-ix8pt",
"generateName": "kubernetes-bootcamp-2321272333-",
"namespace": "default",
"uid": "ba21457c-6b1d-11e6-85f7-1ef9f1dab92b",
"resourceVersion": "33003",
"creationTimestamp": "2016-08-25T23:43:30Z",
"labels": {
"pod-template-hash": "2321272333",
"run": "kubernetes-bootcamp"
},
...
}
kubectl proxy के बारे में और जानें।
Kubernetes v1.24 [stable]
यह पेज दिखाता है कि रिमोट कुबेरनेटेस क्लस्टर के API तक पहुंचने के लिए SOCKS5 प्रॉक्सी का उपयोग कैसे करें। यह तब उपयोगी होता है जब जिस क्लस्टर तक आप पहुंचना चाहते हैं वह अपने API को सीधे सार्वजनिक इंटरनेट पर एक्सपोज़ नहीं करता है।
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
आपका कुबेरनेट्स सर्वर इसपर या इसके बाद के संस्करण पर होना चाहिए v1.24.संस्करण की जांच करने के लिए, लिखें kubectl version.
आपको SSH क्लाइंट सॉफ्टवेयर (ssh टूल) और रिमोट सर्वर पर चलने वाली SSH सेवा की आवश्यकता है।
आपको रिमोट सर्वर पर SSH सेवा में लॉग इन करने में सक्षम होना चाहिए।
चित्र 1 इस टास्क में आप जो प्राप्त करने जा रहे हैं उसे दर्शाता है।
graph LR;
subgraph local[Local client machine]
client([client])-. local
traffic .-> local_ssh[Local SSH
SOCKS5 proxy];
end
local_ssh[SSH
SOCKS5
proxy]-- SSH Tunnel -->sshd
subgraph remote[Remote server]
sshd[SSH
server]-- local traffic -->service1;
end
client([client])-. proxied HTTPs traffic
going through the proxy .->service1[Kubernetes API];
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
class client plain;
class cluster cluster;
निम्नलिखित कमांड आपके क्लाइंट मशीन और रिमोट SOCKS सर्वर के बीच एक SOCKS5 प्रॉक्सी शुरू करता है:
# यह चलाने के बाद SSH टनल फोरग्राउंड में चलता रहता है
ssh -D 1080 -q -N username@kubernetes-remote-server.example
SOCKS5 प्रॉक्सी निम्नलिखित कॉन्फ़िगरेशन के आधार पर आपके क्लस्टर के API सर्वर से कनेक्ट करने देता है:
-D 1080: स्थानीय पोर्ट :1080 पर SOCKS प्रॉक्सी खोलता है।-q: शांत मोड। अधिकांश चेतावनी और नैदानिक संदेशों को दबा देता है।-N: रिमोट कमांड निष्पादित न करें। केवल पोर्ट फॉरवर्ड करने के लिए उपयोगी।username@kubernetes-remote-server.example: रिमोट SSH सर्वर जिसके पीछे कुबेरनेटेस क्लस्टर चल रहा है (उदाहरण: एक बैस्टियन होस्ट)।प्रॉक्सी के माध्यम से कुबेरनेटेस API सर्वर तक पहुंचने के लिए आपको kubectl को निर्देश देना होगा कि वह पहले बनाए गए SOCKS प्रॉक्सी के माध्यम से क्वेरी भेजे। उपयुक्त एनवायरनमेंट वेरिएबल सेट करके या kubeconfig फ़ाइल में proxy-url एट्रिब्यूट के माध्यम से ऐसा करें। एनवायरनमेंट वेरिएबल का उपयोग करते हुए:
export HTTPS_PROXY=socks5://localhost:1080
किसी विशिष्ट kubectl कॉन्टेक्स्ट पर हमेशा इस सेटिंग का उपयोग करने के लिए, ~/.kube/config फ़ाइल के भीतर संबंधित cluster एंट्री में proxy-url एट्रिब्यूट निर्दिष्ट करें। उदाहरण के लिए:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LRMEMMW2 # पठनीयता के लिए संक्षिप्त
server: https://<API_SERVER_IP_ADDRESS>:6443 # "कुबेरनेटेस API" सर्वर, दूसरे शब्दों में kubernetes-remote-server.example का IP पता
proxy-url: socks5://localhost:1080 # ऊपर के चित्र में "SSH SOCKS5 प्रॉक्सी"
name: default
contexts:
- context:
cluster: default
user: default
name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
user:
client-certificate-data: LS0tLS1CR== # पठनीयता के लिए संक्षिप्त
client-key-data: LS0tLS1CRUdJT= # पठनीयता के लिए संक्षिप्त
एक बार जब आप पहले उल्लेखित ssh कमांड के माध्यम से टनल बना लेते हैं, और एनवायरनमेंट वेरिएबल या proxy-url एट्रिब्यूट को परिभाषित कर देते हैं, तो आप उस प्रॉक्सी के माध्यम से अपने क्लस्टर के साथ इंटरैक्ट कर सकते हैं। उदाहरण के लिए:
kubectl get pods
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-85cb69466-klwq8 1/1 Running 0 5m46s
kubectl 1.24 से पहले, सॉक्स प्रॉक्सी का उपयोग करते समय अधिकांश kubectl कमांड काम करते थे, kubectl exec को छोड़कर।kubectl HTTPS_PROXY और https_proxy दोनों एनवायरनमेंट वेरिएबल का समर्थन करता है। इनका उपयोग अन्य प्रोग्राम करते हैं जो SOCKS का समर्थन करते हैं, जैसे curl। इसलिए कुछ मामलों में कमांड लाइन पर एनवायरनमेंट वेरिएबल को परिभाषित करना बेहतर होगा:
HTTPS_PROXY=socks5://localhost:1080 kubectl get pods
proxy-url का उपयोग करते समय, प्रॉक्सी का उपयोग केवल संबंधित kubectl कॉन्टेक्स्ट के लिए किया जाता है,
जबकि एनवायरनमेंट वेरिएबल सभी कॉन्टेक्स्ट को प्रभावित करेगा।socks5 प्रोटोकॉल के बजाय socks5h प्रोटोकॉल नाम का उपयोग करके। इस मामले में, kubectl प्रॉक्सी सर्वर (जैसे ssh बैस्टियन) से k8s API सर्वर डोमेन नाम को रिज़ॉल्व करने के लिए कहेगा, उस सिस्टम पर रिज़ॉल्व करने के बजाय जहां kubectl चल रहा है। ध्यान दें कि socks5h के साथ, https://localhost:6443/api जैसा k8s API सर्वर URL आपके स्थानीय क्लाइंट कंप्यूटर को संदर्भित नहीं करता है। इसके बजाय, यह प्रॉक्सी सर्वर (उदाहरण: ssh बैस्टियन) पर ज्ञात localhost को संदर्भित करता है।जिस टर्मिनल पर यह चल रहा है वहां CTRL+C दबाकर ssh पोर्ट-फॉरवर्डिंग प्रक्रिया को रोकें।
प्रॉक्सी के माध्यम से http ट्रैफ़िक को फॉरवर्ड करना बंद करने के लिए टर्मिनल में unset https_proxy टाइप करें।
यह पेज कुबेरनेट्स पर Antrea CNI प्लगइन को कैसे इंस्टॉल और उपयोग करें, यह दिखाता है। प्रोजेक्ट Antrea की पृष्ठभूमि के लिए, Antrea का परिचय पढ़ें।
आपके पास एक कुबेरनेट्स क्लस्टर होना चाहिए। एक क्लस्टर को बूटस्ट्रैप करने के लिए kubeadm आरंभ करने की गाइड का पालन करें।
kubeadm के लिए Antrea को डिप्लॉय करने के लिए आरंभ करने की गाइड का पालन करें।
एक बार जब आपका क्लस्टर चल रहा हो, तो आप कुबेरनेट्स नेटवर्कपॉलिसी को आज़माने के लिए नेटवर्क पॉलिसी घोषित करें का पालन कर सकते हैं।
यह पेज कुबेरनेट्स पर Calico क्लस्टर बनाने के कुछ त्वरित तरीके दिखाता है।
तय करें कि आप cloud या local क्लस्टर डिप्लॉय करना चाहते हैं।
पूर्वापेक्षा: gcloud।
Calico के साथ GKE क्लस्टर लॉन्च करने के लिए, --enable-network-policy फ्लैग शामिल करें।
सिंटैक्स
gcloud container clusters create [CLUSTER_NAME] --enable-network-policy
उदाहरण
gcloud container clusters create my-calico-cluster --enable-network-policy
डिप्लॉयमेंट को सत्यापित करने के लिए, निम्नलिखित कमांड का उपयोग करें।
kubectl get pods --namespace=kube-system
Calico पॉड्स calico से शुरू होते हैं। जांचें कि प्रत्येक की स्थिति Running है।
kubeadm का उपयोग करके पंद्रह मिनट में एक लोकल सिंगल-होस्ट Calico क्लस्टर प्राप्त करने के लिए, Calico क्विकस्टार्ट देखें।
एक बार जब आपका क्लस्टर चल रहा हो, तो आप कुबेरनेट्स नेटवर्कपॉलिसी को आज़माने के लिए नेटवर्क पॉलिसी घोषित करें का पालन कर सकते हैं।
Konnectivity सेवा कंट्रोल प्लेन से क्लस्टर संचार के लिए TCP स्तर का प्रॉक्सी प्रदान करती है।
आपके पास एक कुबेरनेटेस क्लस्टर होना चाहिए, और kubectl कमांड-लाइन टूल को आपके क्लस्टर के साथ संवाद करने के लिए कॉन्फ़िगर किया जाना चाहिए। इस ट्यूटोरियल को कम से कम दो नोड्स वाले क्लस्टर पर चलाने की सलाह दी जाती है जो कंट्रोल प्लेन होस्ट के रूप में कार्य नहीं कर रहे हैं। यदि आपके पास पहले से कोई क्लस्टर नहीं है, तो आप इसे minikube का उपयोग करके बना सकते हैं।
निम्नलिखित चरणों के लिए एक egress कॉन्फ़िगरेशन की आवश्यकता है, उदाहरण के लिए:
apiVersion: apiserver.k8s.io/v1beta1
kind: EgressSelectorConfiguration
egressSelections:
# Since we want to control the egress traffic to the cluster, we use the
# "cluster" as the name. Other supported values are "etcd", and "controlplane".
- name: cluster
connection:
# This controls the protocol between the API Server and the Konnectivity
# server. Supported values are "GRPC" and "HTTPConnect". There is no
# end user visible difference between the two modes. You need to set the
# Konnectivity server to work in the same mode.
proxyProtocol: GRPC
transport:
# This controls what transport the API Server uses to communicate with the
# Konnectivity server. UDS is recommended if the Konnectivity server
# locates on the same machine as the API Server. You need to configure the
# Konnectivity server to listen on the same UDS socket.
# The other supported transport is "tcp". You will need to set up TLS
# config to secure the TCP transport.
uds:
udsName: /etc/kubernetes/konnectivity-server/konnectivity-server.socket
आपको API सर्वर को Konnectivity सेवा का उपयोग करने और नेटवर्क ट्रैफ़िक को क्लस्टर नोड्स की ओर निर्देशित करने के लिए कॉन्फ़िगर करना होगा:
सुनिश्चित करें कि आपके क्लस्टर में Service Account Token Volume Projection फ़ीचर सक्षम है। यह Kubernetes v1.20 से डिफ़ॉल्ट रूप से सक्षम है।
admin/konnectivity/egress-selector-configuration.yaml जैसी एक egress कॉन्फ़िगरेशन फ़ाइल बनाएं।
API सर्वर के --egress-selector-config-file फ़्लैग को आपकी API सर्वर egress कॉन्फ़िगरेशन फ़ाइल के पथ पर सेट करें।
यदि आप UDS कनेक्शन का उपयोग करते हैं, तो kube-apiserver में volumes कॉन्फ़िगरेशन जोड़ें:
spec:
containers:
volumeMounts:
- name: konnectivity-uds
mountPath: /etc/kubernetes/konnectivity-server
readOnly: false
volumes:
- name: konnectivity-uds
hostPath:
path: /etc/kubernetes/konnectivity-server
type: DirectoryOrCreate
konnectivity-server के लिए एक प्रमाणपत्र और kubeconfig जेनरेट करें या प्राप्त करें।
उदाहरण के लिए, आप एक X.509 प्रमाणपत्र जारी करने के लिए OpenSSL कमांड लाइन टूल का उपयोग कर सकते हैं,
कंट्रोल-प्लेन होस्ट से क्लस्टर CA प्रमाणपत्र /etc/kubernetes/pki/ca.crt का उपयोग करके।
openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key
openssl x509 -req -in konnectivity.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out konnectivity.crt -days 375 -sha256
SERVER=$(kubectl config view -o jsonpath='{.clusters..server}')
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-credentials system:konnectivity-server --client-certificate konnectivity.crt --client-key konnectivity.key --embed-certs=true
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-cluster kubernetes --server "$SERVER" --certificate-authority /etc/kubernetes/pki/ca.crt --embed-certs=true
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-context system:konnectivity-server@kubernetes --cluster kubernetes --user system:konnectivity-server
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config use-context system:konnectivity-server@kubernetes
rm -f konnectivity.crt konnectivity.key konnectivity.csr
इसके बाद, आपको Konnectivity सर्वर और एजेंट्स को डिप्लॉय करना होगा। kubernetes-sigs/apiserver-network-proxy एक संदर्भ कार्यान्वयन है।
अपने कंट्रोल प्लेन नोड पर Konnectivity सर्वर को डिप्लॉय करें। प्रदान किया गया
konnectivity-server.yaml मैनिफेस्ट मानता है
कि Kubernetes कंपोनेंट्स आपके क्लस्टर में एक static Pod के रूप में डिप्लॉय किए गए हैं। यदि नहीं, तो आप Konnectivity
सर्वर को एक DaemonSet के रूप में डिप्लॉय कर सकते हैं।
apiVersion: v1
kind: Pod
metadata:
name: konnectivity-server
namespace: kube-system
spec:
priorityClassName: system-cluster-critical
hostNetwork: true
containers:
- name: konnectivity-server-container
image: registry.k8s.io/kas-network-proxy/proxy-server:v0.0.37
command: ["/proxy-server"]
args: [
"--logtostderr=true",
# This needs to be consistent with the value set in egressSelectorConfiguration.
"--uds-name=/etc/kubernetes/konnectivity-server/konnectivity-server.socket",
"--delete-existing-uds-file",
# The following two lines assume the Konnectivity server is
# deployed on the same machine as the apiserver, and the certs and
# key of the API Server are at the specified location.
"--cluster-cert=/etc/kubernetes/pki/apiserver.crt",
"--cluster-key=/etc/kubernetes/pki/apiserver.key",
# This needs to be consistent with the value set in egressSelectorConfiguration.
"--mode=grpc",
"--server-port=0",
"--agent-port=8132",
"--admin-port=8133",
"--health-port=8134",
"--agent-namespace=kube-system",
"--agent-service-account=konnectivity-agent",
"--kubeconfig=/etc/kubernetes/konnectivity-server.conf",
"--authentication-audience=system:konnectivity-server"
]
livenessProbe:
httpGet:
scheme: HTTP
host: 127.0.0.1
port: 8134
path: /healthz
initialDelaySeconds: 30
timeoutSeconds: 60
ports:
- name: agentport
containerPort: 8132
hostPort: 8132
- name: adminport
containerPort: 8133
hostPort: 8133
- name: healthport
containerPort: 8134
hostPort: 8134
volumeMounts:
- name: k8s-certs
mountPath: /etc/kubernetes/pki
readOnly: true
- name: kubeconfig
mountPath: /etc/kubernetes/konnectivity-server.conf
readOnly: true
- name: konnectivity-uds
mountPath: /etc/kubernetes/konnectivity-server
readOnly: false
volumes:
- name: k8s-certs
hostPath:
path: /etc/kubernetes/pki
- name: kubeconfig
hostPath:
path: /etc/kubernetes/konnectivity-server.conf
type: FileOrCreate
- name: konnectivity-uds
hostPath:
path: /etc/kubernetes/konnectivity-server
type: DirectoryOrCreate
फिर अपने क्लस्टर में Konnectivity एजेंट्स को डिप्लॉय करें:
apiVersion: apps/v1
# Alternatively, you can deploy the agents as Deployments. It is not necessary
# to have an agent on each node.
kind: DaemonSet
metadata:
labels:
addonmanager.kubernetes.io/mode: Reconcile
k8s-app: konnectivity-agent
namespace: kube-system
name: konnectivity-agent
spec:
selector:
matchLabels:
k8s-app: konnectivity-agent
template:
metadata:
labels:
k8s-app: konnectivity-agent
spec:
priorityClassName: system-cluster-critical
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.37
name: konnectivity-agent
command: ["/proxy-agent"]
args: [
"--logtostderr=true",
"--ca-cert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt",
# Since the konnectivity server runs with hostNetwork=true,
# this is the IP address of the master machine.
"--proxy-server-host=35.225.206.7",
"--proxy-server-port=8132",
"--admin-server-port=8133",
"--health-server-port=8134",
"--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token"
]
volumeMounts:
- mountPath: /var/run/secrets/tokens
name: konnectivity-agent-token
livenessProbe:
httpGet:
port: 8134
path: /healthz
initialDelaySeconds: 15
timeoutSeconds: 15
serviceAccountName: konnectivity-agent
volumes:
- name: konnectivity-agent-token
projected:
sources:
- serviceAccountToken:
path: konnectivity-agent-token
audience: system:konnectivity-server
अंत में, यदि आपके क्लस्टर में RBAC सक्षम है, तो संबंधित RBAC नियम बनाएं:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: system:konnectivity-server
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:auth-delegator
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: system:konnectivity-server
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: konnectivity-agent
namespace: kube-system
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
यह पृष्ठ दिखाता है कि क्यूबलेट के लिए प्रमाणपत्र आवर्तन कैसे सक्षम और कॉन्फ़िगर कर सकते है।
Kubernetes v1.19 [stable]
क्यूबलेट प्रमाणपत्रों का उपयोग कुबरनेट्स API के साथ प्रमाणित करने के लिए करता है। डिफ़ॉल्ट रूप से, ये प्रमाणपत्र एक वर्ष की समाप्ति के साथ जारी किए जाते हैं ताकि उन्हें बार-बार नवीनीकृत करने की आवश्यकता न हो।
कुबरनेट्स में क्यूबलेट प्रमाणपत्र आवर्तन शामिल है, जो स्वचालित रूप से एक नई कुंजी उत्पन्न करेगा जो स्वचालित रूप से एक नई कुंजी उत्पन्न करेगा और वर्तमान प्रमाणपत्र की समाप्ति के करीब आने पर कुबरनेट्स API से एक नया प्रमाणपत्र अनुरोध करेगा। एक बार नया प्रमाणपत्र उपलब्ध हो जाने पर, यह कुबरनेट्स API के साथ कनेक्शन को प्रमाणित करने के लिए उपयोग किया जाएगा।
kubelet प्रक्रिया एक प्राचल --rotate-certificates स्वीकार करती है जो नियंत्रित करती है कि क्या कुबलेट स्वचालित रूप से वर्तमान में उपयोग किए जा रहे प्रमाणपत्र की समाप्ति के करीब आने पर एक नया प्रमाणपत्र अनुरोध करेगा।
kube-controller-manager प्रक्रिया एक प्राचल स्वीकार करती है
--cluster-signing-duration (--experimental-cluster-signing-duration 1.19 से पहले)
जो नियंत्रित करता है कि प्रमाणपत्र कितने समय के लिए जारी किए जाएंगे।
जब एक कुबलेट शुरू होता है, यदि इसे बूटस्ट्रैप करने के लिए कॉन्फ़िगर किया गया है (उपयोग करते हुए
--bootstrap-kubeconfig फ्लैग), तो यह कुबरनेट्स API से कनेक्ट करने और एक प्रमाणपत्र हस्ताक्षर अनुरोध जारी करने के लिए अपने प्रारंभिक प्रमाणपत्र का उपयोग करेगा। आप प्रमाणपत्र हस्ताक्षर अनुरोधों की स्थिति देख सकते हैं:
kubectl get csr
शुरुआत में, किसी नोड पर कुबलेट से एक प्रमाणपत्र हस्ताक्षर अनुरोध की स्थिति Pending होगी।
यदि प्रमाणपत्र हस्ताक्षर अनुरोध विशिष्ट मानदंडों को पूरा करता है, तो इसे नियंत्रक प्रबंधक द्वारा स्वचालित रूप से अनुमोदित किया जाएगा, और फिर इसकी स्थिति Approved होगी।
इसके बाद, नियंत्रक प्रबंधक एक प्रमाणपत्र पर हस्ताक्षर करेगा, जो
--cluster-signing-duration पैरामीटर द्वारा निर्दिष्ट अवधि के लिए जारी किया जाएगा, और हस्ताक्षरित प्रमाणपत्र को प्रमाणपत्र हस्ताक्षर अनुरोध से जोड़ा जाएगा।
कुबलेट कुबरनेट्स API से हस्ताक्षरित प्रमाणपत्र प्राप्त करेगा और इसे डिस्क पर लिखेगा,
--cert-dir द्वारा निर्दिष्ट स्थान में। फिर कुबलेट कुबरनेट्स API से कनेक्ट करने के लिए नए प्रमाणपत्र का उपयोग करेगा।
जैसे ही हस्ताक्षरित प्रमाणपत्र की समाप्ति निकट आती है, कुबलेट स्वचालित रूप से कुबरनेट्स API का उपयोग करके एक नया प्रमाणपत्र हस्ताक्षर अनुरोध जारी करेगा। यह प्रमाणपत्र पर शेष समय के 30% और 10% के बीच किसी भी बिंदु पर हो सकता है। फिर से, नियंत्रक प्रबंधक स्वचालित रूप से प्रमाणपत्र अनुरोध को अनुमोदित करेगा और प्रमाणपत्र हस्ताक्षर अनुरोध से एक हस्ताक्षरित प्रमाणपत्र जोड़ेगा। कुबलेट कुबरनेट्स API से नया हस्ताक्षरित प्रमाणपत्र प्राप्त करेगा और इसे डिस्क पर लिखेगा। फिर यह कुबरनेट्स API के साथ कनेक्शन को नए प्रमाणपत्र का उपयोग करके पुन: कनेक्ट करने के लिए अपडेट करेगा।