ວິທີການໃຊ້ kubectl ມີປະສິດທິພາບຫຼາຍຂຶ້ນ: ຄູ່ມືລາຍລະອຽດ

ຖ້າທ່ານເຮັດວຽກກັບ Kubernetes, kubectl ແມ່ນອາດຈະເປັນຫນຶ່ງຂອງຜົນປະໂຫຍດທີ່ທ່ານໃຊ້ຫຼາຍທີ່ສຸດ. ແລະທຸກຄັ້ງທີ່ທ່ານໃຊ້ເວລາຫຼາຍໃນການເຮັດວຽກກັບເຄື່ອງມືສະເພາະໃດຫນຶ່ງ, ມັນຈ່າຍເງິນເພື່ອສຶກສາມັນດີແລະຮຽນຮູ້ວິທີການນໍາໃຊ້ມັນຢ່າງມີປະສິດທິພາບ.

ທີມງານ Kubernetes aaS ຈາກ Mail.ru ແປບົດຄວາມໂດຍ Daniel Weibel ທີ່ເຈົ້າຈະພົບເຫັນຄໍາແນະນໍາແລະຄໍາແນະນໍາສໍາລັບການເຮັດວຽກທີ່ມີປະສິດທິພາບກັບ kubectl. ມັນຍັງຈະຊ່ວຍໃຫ້ທ່ານມີຄວາມເຂົ້າໃຈເລິກເຊິ່ງກ່ຽວກັບ Kubernetes.

ອີງຕາມຜູ້ຂຽນ, ເປົ້າຫມາຍຂອງບົດຄວາມແມ່ນເພື່ອເຮັດໃຫ້ການເຮັດວຽກປະຈໍາວັນຂອງທ່ານກັບ Kubernetes ບໍ່ພຽງແຕ່ມີປະສິດທິພາບ, ແຕ່ຍັງມີຄວາມສຸກຫຼາຍ!

ແນະນໍາ: kubectl ແມ່ນຫຍັງ

ກ່ອນທີ່ທ່ານຈະສາມາດຮຽນຮູ້ການນໍາໃຊ້ kubectl ໄດ້ປະສິດທິພາບຫຼາຍ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ເຂົ້າໃຈພື້ນຖານຂອງສິ່ງທີ່ມັນແມ່ນແລະວິທີການເຮັດວຽກ.

ຈາກທັດສະນະຂອງຜູ້ໃຊ້, kubectl ແມ່ນແຜງຄວບຄຸມທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດດໍາເນີນການ Kubernetes ໄດ້.

ເວົ້າທາງວິຊາການ, kubectl ແມ່ນລູກຄ້າ Kubernetes API.

Kubernetes API ແມ່ນ HTTP REST API. API ນີ້ແມ່ນການໂຕ້ຕອບຜູ້ໃຊ້ Kubernetes ທີ່ແທ້ຈິງ, ໂດຍຜ່ານທີ່ມັນຖືກຄວບຄຸມຢ່າງສົມບູນ. ນີ້ຫມາຍຄວາມວ່າທຸກໆການດໍາເນີນງານ Kubernetes ຖືກເປີດເຜີຍເປັນຈຸດສິ້ນສຸດ API ແລະສາມາດເຮັດໄດ້ດ້ວຍການຮ້ອງຂໍ HTTP ໄປຫາຈຸດສິ້ນສຸດນັ້ນ.

ດັ່ງນັ້ນ, ວຽກງານຕົ້ນຕໍຂອງ kubectl ແມ່ນເພື່ອເຮັດໃຫ້ການຮ້ອງຂໍ HTTP ກັບ Kubernetes API:

Kubernetes ແມ່ນລະບົບທີ່ເນັ້ນໃສ່ຊັບພະຍາກອນຢ່າງສົມບູນ. ນີ້ຫມາຍຄວາມວ່າມັນຮັກສາສະຖານະພາຍໃນຂອງຊັບພະຍາກອນແລະການດໍາເນີນງານ Kubernetes ທັງຫມົດແມ່ນການດໍາເນີນງານ CRUD.

ທ່ານຢູ່ໃນການຄວບຄຸມຂອງ Kubernetes ຢ່າງສົມບູນໂດຍການຄຸ້ມຄອງຊັບພະຍາກອນເຫຼົ່ານີ້, ແລະ Kubernetes ຄິດໄລ່ສິ່ງທີ່ຕ້ອງເຮັດໂດຍອີງໃສ່ສະຖານະການໃນປະຈຸບັນຂອງຊັບພະຍາກອນ. ດ້ວຍເຫດຜົນນີ້, ການອ້າງອີງ Kubernetes API ໄດ້ຖືກຈັດເປັນບັນຊີລາຍຊື່ຂອງປະເພດຊັບພະຍາກອນທີ່ມີການດໍາເນີນງານທີ່ກ່ຽວຂ້ອງຂອງພວກເຂົາ.

ໃຫ້ເບິ່ງຕົວຢ່າງ.

ໃຫ້ເວົ້າວ່າທ່ານຕ້ອງການສ້າງຊັບພະຍາກອນ ReplicaSet. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານອະທິບາຍຊຸດ ReplicaSet ໃນໄຟລ໌ໂດຍຊື່ replicaset.yaml, ຫຼັງຈາກນັ້ນດໍາເນີນການຄໍາສັ່ງ:

$ kubectl create -f replicaset.yaml

ນີ້ຈະສ້າງຊັບພະຍາກອນ ReplicaSet. ແຕ່ສິ່ງທີ່ເກີດຂຶ້ນຢູ່ເບື້ອງຫຼັງ?

Kubernetes ມີການດໍາເນີນງານການສ້າງ ReplicaSet. ເຊັ່ນດຽວກັນກັບການດໍາເນີນງານອື່ນໆ, ມັນຖືກເປີດເຜີຍເປັນຈຸດສິ້ນສຸດ API. ຈຸດສິ້ນສຸດ API ສະເພາະສໍາລັບການປະຕິບັດງານນີ້ເບິ່ງຄືວ່າ:

POST /apis/apps/v1/namespaces/{namespace}/replicasets

ຈຸດສິ້ນສຸດ API ສໍາລັບການປະຕິບັດງານ Kubernetes ທັງໝົດສາມາດພົບໄດ້ທີ່ ອ້າງອີງ API (ລວມທັງ ຈຸດສິ້ນສຸດຂ້າງເທິງ). ເພື່ອເຮັດການຮ້ອງຂໍຕົວຈິງໄປຫາຈຸດສິ້ນສຸດ, ກ່ອນອື່ນ ໝົດ ທ່ານຕ້ອງເພີ່ມ URL ເຊີບເວີ API ໃສ່ເສັ້ນທາງປາຍທາງທີ່ລະບຸໄວ້ໃນເອກະສານອ້າງອີງ API.

ດັ່ງນັ້ນ, ເມື່ອທ່ານປະຕິບັດຄໍາສັ່ງຂ້າງເທິງ, kubectl ສົ່ງຄໍາຮ້ອງຂໍ HTTP POST ໄປຫາຈຸດສິ້ນສຸດ API ຂ້າງເທິງ. ຄໍານິຍາມ ReplicaSet ທີ່ທ່ານລະບຸໄວ້ໃນໄຟລ໌ replicaset.yaml, ຖືກສົ່ງຢູ່ໃນຮ່າງກາຍຂອງຄໍາຮ້ອງຂໍ.

ນີ້ແມ່ນວິທີທີ່ kubectl ເຮັດວຽກສໍາລັບຄໍາສັ່ງທັງຫມົດທີ່ພົວພັນກັບກຸ່ມ Kubernetes. ໃນທຸກກໍລະນີເຫຼົ່ານີ້, kubectl ພຽງແຕ່ເຮັດການຮ້ອງຂໍ HTTP ໄປຫາຈຸດສິ້ນສຸດ Kubernetes API ທີ່ເຫມາະສົມ.

ກະລຸນາຮັບຊາບວ່າທ່ານສາມາດຈັດການ Kubernetes ຢ່າງເຕັມສ່ວນໂດຍໃຊ້ປະໂຫຍດເຊັ່ນ: curlໂດຍການສົ່ງຄໍາຮ້ອງຂໍ HTTP ໄປຫາ Kubernetes API ດ້ວຍຕົນເອງ. Kubectl ພຽງແຕ່ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການໃຊ້ Kubernetes API.

ນີ້ແມ່ນພື້ນຖານຂອງ kubectl ແມ່ນຫຍັງແລະວິທີການເຮັດວຽກ. ແຕ່ມີບາງສິ່ງບາງຢ່າງອື່ນກ່ຽວກັບ Kubernetes API ທີ່ຜູ້ໃຊ້ kubectl ທຸກຄົນຄວນຮູ້. ລອງເບິ່ງໂລກພາຍໃນຂອງ Kubernetes ໄວໆ.

ໂລກພາຍໃນຂອງ Kubernetes

Kubernetes ປະກອບດ້ວຍຊຸດຂອງອົງປະກອບເອກະລາດທີ່ດໍາເນີນການເປັນຂະບວນການແຍກຕ່າງຫາກຢູ່ໃນ cluster nodes. ອົງປະກອບບາງອັນເຮັດວຽກຢູ່ໃນໂຫມດຕົ້ນສະບັບ, ອົງປະກອບອື່ນໆໃນໂຫມດຜູ້ເຮັດວຽກ, ແຕ່ລະອົງປະກອບປະຕິບັດວຽກງານສະເພາະຂອງຕົນເອງ.

ນີ້ແມ່ນອົງປະກອບທີ່ສໍາຄັນທີ່ສຸດໃນ nodes ຕົ້ນຕໍ:

1. ວໍ້ - ການ​ເກັບ​ກໍາ​ຄໍາ​ນິ​ຍາມ​ຂອງ​ຊັບ​ພະ​ຍາ​ກອນ (ປົກກະຕິແລ້ວມັນເປັນ etcd).
2. ເຊີບເວີ API — ສະ​ຫນອງ API ແລະ​ຄຸ້ມ​ຄອງ​ການ​ເກັບ​ຮັກ​ສາ​.
3. ຜູ້ຈັດການຄວບຄຸມ — ຮັບ​ປະ​ກັນ​ວ່າ​ສະ​ຖາ​ນະ​ຊັບ​ພະ​ຍາ​ກອນ​ປະ​ຕິ​ບັດ​ຕາມ​ສະ​ເພາະ​.
4. ຜູ້ຈັດຕາຕະລາງ — ກໍາ​ນົດ​ເວ​ລາ pods ໃນ nodes ຂອງ​ພະ​ນັກ​ງານ​.

ແລະນີ້ແມ່ນອົງປະກອບ ໜຶ່ງ ທີ່ ສຳ ຄັນທີ່ສຸດໃນຂໍ້ຂອງພະນັກງານ:

1. ຄູເບເລດ — ຄຸ້ມ​ຄອງ​ການ​ເປີດ​ຕົວ​ບັນຈຸ​ຢູ່​ເທິງ​ຂໍ້​ມູນ​ທີ່​ເຮັດ​ວຽກ.

ເພື່ອເຂົ້າໃຈວ່າອົງປະກອບເຫຼົ່ານີ້ເຮັດວຽກຮ່ວມກັນແນວໃດ, ໃຫ້ເບິ່ງຕົວຢ່າງ.

ໃຫ້ສົມມຸດວ່າທ່ານຫາກໍ່ສໍາເລັດ kubectl create -f replicaset.yaml, ຫຼັງຈາກນັ້ນ kubectl ໄດ້ຮ້ອງຂໍ HTTP POST ກັບ ReplicaSet API endpoint (ຜ່ານຄໍານິຍາມຊັບພະຍາກອນ ReplicaSet).

ມີຫຍັງເກີດຂຶ້ນໃນກຸ່ມ?

1. ຫຼັງຈາກເຮັດ kubectl create -f replicaset.yaml ເຊີບເວີ API ເກັບຄໍານິຍາມຊັບພະຍາກອນ ReplicaSet ຂອງທ່ານໃນບ່ອນເກັບຂໍ້ມູນ:

   

2. ຕໍ່ໄປ, ຕົວຄວບຄຸມ ReplicaSet ຖືກເປີດຕົວໃນຕົວຈັດການຄວບຄຸມ, ເຊິ່ງຈັດການການສ້າງ, ດັດແກ້ແລະການລຶບຊັບພະຍາກອນ ReplicaSet:

   

3. ຕົວຄວບຄຸມ ReplicaSet ສ້າງຄໍານິຍາມ pod ສໍາລັບແຕ່ລະ replicaSet replica (ອີງຕາມແມ່ແບບ pod ໃນຄໍານິຍາມ ReplicaSet) ແລະເກັບຮັກສາໃຫ້ເຂົາເຈົ້າຢູ່ໃນບ່ອນເກັບຮັກສາ:

   

4. ຕົວກຳນົດເວລາຖືກເປີດຕົວ, ຕິດຕາມຝັກທີ່ຍັງບໍ່ທັນໄດ້ມອບໝາຍໃຫ້ຜູ້ອອກແຮງງານໃດໆ:

   

5. ຜູ້ຈັດຕາຕະລາງເລືອກ node ພະນັກງານທີ່ເຫມາະສົມສໍາລັບແຕ່ລະ pod ແລະເພີ່ມຂໍ້ມູນນີ້ໃສ່ຄໍານິຍາມ pod ໃນຮ້ານ:

   

6. ໃນ node ພະນັກງານທີ່ pods ຖືກມອບຫມາຍ, Kubelet ຖືກເປີດຕົວ, ມັນຕິດຕາມ pods ທີ່ຖືກມອບຫມາຍໃຫ້ກັບ node ນີ້:

   

7. Kubelet ອ່ານຄຳນິຍາມຂອງພອດຈາກບ່ອນເກັບມ້ຽນ ແລະສັ່ງໃຫ້ໃຊ້ container runtime ເຊັ່ນ Docker ເພື່ອເປີດ containers ໃນ node:

   

ຂ້າງລຸ່ມນີ້ແມ່ນສະບັບຂໍ້ຄວາມຂອງຄໍາອະທິບາຍນີ້.

ການຮ້ອງຂໍ API ໄປຫາຈຸດສິ້ນສຸດການສ້າງ ReplicaSet ຖືກປະມວນຜົນໂດຍເຊີບເວີ API. ເຊີບເວີ API ກວດສອບການຮ້ອງຂໍ ແລະເກັບຮັກສາຄໍານິຍາມຊັບພະຍາກອນ ReplicaSet ໄວ້ໃນບ່ອນເກັບຂໍ້ມູນ.

ເຫດການນີ້ເລີ່ມຕົ້ນຕົວຄວບຄຸມ ReplicaSet, ເຊິ່ງເປັນຂະບວນການຍ່ອຍຂອງຜູ້ຈັດການຄວບຄຸມ. ຕົວຄວບຄຸມ ReplicaSet ຕິດຕາມການສ້າງ, ການປັບປຸງ, ແລະການລຶບຊັບພະຍາກອນ ReplicaSet ໃນຮ້ານແລະໄດ້ຮັບການແຈ້ງເຕືອນເຫດການເມື່ອເຫດການນີ້ເກີດຂຶ້ນ.

ວຽກຂອງຕົວຄວບຄຸມ ReplicaSet ແມ່ນເພື່ອໃຫ້ແນ່ໃຈວ່າມີຈໍານວນ ReplicaSet ທີ່ຕ້ອງການ. ໃນຕົວຢ່າງຂອງພວກເຮົາ, ບໍ່ມີຝັກໃດໆ, ດັ່ງນັ້ນຕົວຄວບຄຸມ ReplicaSet ສ້າງຄໍານິຍາມ pod ເຫຼົ່ານີ້ (ອີງຕາມແມ່ແບບຝັກໃນຄໍານິຍາມ ReplicaSet) ແລະເກັບຮັກສາໄວ້ໃນບ່ອນເກັບມ້ຽນ.

ການສ້າງ pods ໃຫມ່ແມ່ນກະຕຸ້ນໂດຍຕົວກໍານົດເວລາທີ່ຕິດຕາມຄໍານິຍາມ pods ທີ່ຍັງບໍ່ທັນໄດ້ກໍານົດເວລາສໍາລັບ nodes ພະນັກງານ. ຜູ້ຈັດຕາຕະລາງເລືອກ node ພະນັກງານທີ່ເຫມາະສົມສໍາລັບແຕ່ລະ pod ແລະປັບປຸງຄໍານິຍາມ pod ໃນ repository.

ຈົ່ງຈື່ໄວ້ວ່າຈົນເຖິງຈຸດນີ້, ບໍ່ມີລະຫັດວຽກໃດທີ່ເຮັດວຽກຢູ່ໃນກຸ່ມ. ທຸກສິ່ງທຸກຢ່າງທີ່ໄດ້ເຮັດມາເຖິງຕອນນັ້ນ - ນີ້ແມ່ນການສ້າງແລະປັບປຸງຊັບພະຍາກອນໃນ repository ໃນ master node.

ເຫດການສຸດທ້າຍກະຕຸ້ນ Kubelets, ເຊິ່ງຕິດຕາມກວດກາ pods ທີ່ກໍານົດໄວ້ສໍາລັບ nodes ພະນັກງານຂອງເຂົາເຈົ້າ. Kubelet ຂອງ node worker ທີ່ຕິດຕັ້ງພອດ ReplicaSet ຂອງທ່ານຕ້ອງສັ່ງໃຫ້ container runtime, ເຊັ່ນ Docker, ເພື່ອດາວໂຫລດຮູບພາບ container ທີ່ຕ້ອງການແລະດໍາເນີນການໃຫ້ເຂົາເຈົ້າ.

ໃນຈຸດນີ້, ຄໍາຮ້ອງສະຫມັກ ReplicaSet ຂອງເຈົ້າກໍາລັງແລ່ນໃນທີ່ສຸດ!

ບົດບາດຂອງ Kubernetes API

ດັ່ງທີ່ທ່ານເຫັນໃນຕົວຢ່າງທີ່ຜ່ານມາ, ອົງປະກອບ Kubernetes (ຍົກເວັ້ນເຄື່ອງແມ່ຂ່າຍ API ແລະການເກັບຮັກສາ) ເບິ່ງການປ່ຽນແປງຊັບພະຍາກອນໃນການເກັບຮັກສາແລະການປ່ຽນແປງຂໍ້ມູນກ່ຽວກັບຊັບພະຍາກອນໃນການເກັບຮັກສາ.

ແນ່ນອນ, ອົງປະກອບເຫຼົ່ານີ້ບໍ່ໄດ້ພົວພັນກັບການເກັບຮັກສາໂດຍກົງ, ແຕ່ຜ່ານ Kubernetes API ເທົ່ານັ້ນ.

ພິຈາລະນາຕົວຢ່າງຕໍ່ໄປນີ້:

1. ຕົວຄວບຄຸມ ReplicaSet ໃຊ້ຈຸດສິ້ນສຸດ API ບັນຊີລາຍຊື່ ReplicaSets ກັບພາລາມິເຕີ watch ເພື່ອຕິດຕາມການປ່ຽນແປງຂອງຊັບພະຍາກອນ ReplicaSet.
2. ຕົວຄວບຄຸມ ReplicaSet ໃຊ້ຈຸດສິ້ນສຸດ API ສ້າງ Pod (ສ້າງຝັກ) ເພື່ອສ້າງຝັກ.
3. Scheduler ໃຊ້ API endpoint ຝັກ (ແກ້ໄຂ pod) ເພື່ອປັບປຸງ pods ກັບຂໍ້ມູນກ່ຽວກັບ node ພະນັກງານເລືອກ.

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ນີ້ແມ່ນ API ດຽວກັນທີ່ kubectl ເຂົ້າເຖິງ. ການນໍາໃຊ້ API ດຽວກັນສໍາລັບອົງປະກອບພາຍໃນແລະຜູ້ໃຊ້ພາຍນອກແມ່ນແນວຄວາມຄິດພື້ນຖານໃນການອອກແບບ Kubernetes.

ຕອນນີ້ພວກເຮົາສາມາດສະຫຼຸບວິທີການເຮັດວຽກ Kubernetes:

1. ການເກັບຮັກສາເກັບຮັກສາລັດ, ນັ້ນແມ່ນ, ຊັບພະຍາກອນ Kubernetes.
2. ເຊີບເວີ API ໃຫ້ສ່ວນຕິດຕໍ່ກັບບ່ອນເກັບຂໍ້ມູນໃນຮູບແບບຂອງ Kubernetes API.
3. ອົງ​ປະ​ກອບ Kubernetes ອື່ນໆ​ທັງ​ຫມົດ​ແລະ​ຜູ້​ໃຊ້​ອ່ານ, ສັງ​ເກດ, ແລະ manipulate ລັດ Kubernetes (ຊັບພະຍາກອນ) ຜ່ານ API.

ການຮູ້ແນວຄວາມຄິດເຫຼົ່ານີ້ຈະຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈ kubectl ໄດ້ດີຂຶ້ນແລະໄດ້ຮັບປະໂຫຍດສູງສຸດຈາກມັນ.

ຕອນນີ້ໃຫ້ເບິ່ງບາງຄໍາແນະນໍາສະເພາະແລະ tricks ທີ່ຈະຊ່ວຍປັບປຸງການຜະລິດຂອງທ່ານດ້ວຍ kubectl.

1. ເລັ່ງການປ້ອນຂໍ້ມູນໂດຍໃຊ້ຄໍາສັ່ງສໍາເລັດ

ຫນຶ່ງໃນທີ່ເປັນປະໂຫຍດທີ່ສຸດ, ແຕ່ມັກຈະຖືກມອງຂ້າມ, ເຕັກນິກການປັບປຸງການປະຕິບັດດ້ວຍ kubectl ແມ່ນການສໍາເລັດຄໍາສັ່ງ.

ການສໍາເລັດຄໍາສັ່ງອະນຸຍາດໃຫ້ທ່ານເຮັດສໍາເລັດພາກສ່ວນຂອງຄໍາສັ່ງ kubectl ອັດຕະໂນມັດໂດຍໃຊ້ປຸ່ມ Tab. ນີ້ເຮັດວຽກສໍາລັບຄໍາສັ່ງຍ່ອຍ, ທາງເລືອກ, ແລະການໂຕ້ຖຽງ, ລວມທັງບາງສິ່ງບາງຢ່າງທີ່ສະລັບສັບຊ້ອນເປັນຊື່ຊັບພະຍາກອນ.

ເບິ່ງວິທີການສໍາເລັດຄໍາສັ່ງ kubectl ເຮັດວຽກ:

ການສໍາເລັດຄໍາສັ່ງເຮັດວຽກສໍາລັບ Shell Bash ແລະ Zsh.

ຄູ່ມືທາງການ ປະກອບມີຄໍາແນະນໍາຢ່າງລະອຽດສໍາລັບການຕັ້ງຄ່າການຕື່ມຂໍ້ມູນອັດຕະໂນມັດ, ແຕ່ຂ້າງລຸ່ມນີ້ພວກເຮົາຈະສະຫນອງການຫຍໍ້ມາຈາກສັ້ນ.

ວິທີການສໍາເລັດຄໍາສັ່ງເຮັດວຽກ

ການສໍາເລັດຄໍາສັ່ງແມ່ນຄຸນນະສົມບັດ shell ທີ່ເຮັດວຽກໂດຍໃຊ້ script ສໍາເລັດ. ສະຄຣິບສ່ວນຂະຫຍາຍແມ່ນສະຄຣິບ shell ທີ່ກໍານົດພຶດຕິກໍາຂອງສ່ວນຂະຫຍາຍສໍາລັບຄໍາສັ່ງສະເພາະ.

Kubectl ອັດຕະໂນມັດສ້າງແລະສົ່ງສະຄິບຂະຫຍາຍສໍາລັບ Bash ແລະ Zsh ໂດຍໃຊ້ຄໍາສັ່ງຕໍ່ໄປນີ້:

$ kubectl completion bash

ຫລື:

$ kubectl completion zsh

ໃນທາງທິດສະດີ, ມັນພຽງພໍທີ່ຈະເຊື່ອມຕໍ່ຜົນຜະລິດຂອງຄໍາສັ່ງເຫຼົ່ານີ້ກັບແກະຄໍາສັ່ງທີ່ເຫມາະສົມເພື່ອໃຫ້ kubectl ສາມາດປະກອບຄໍາສັ່ງ.

ໃນການປະຕິບັດ, ວິທີການເຊື່ອມຕໍ່ແມ່ນແຕກຕ່າງກັນສໍາລັບ Bash (ລວມທັງຄວາມແຕກຕ່າງລະຫວ່າງ Linux ແລະ MacOS) ແລະ Zsh. ຂ້າງລຸ່ມນີ້ພວກເຮົາຈະເບິ່ງທາງເລືອກເຫຼົ່ານີ້ທັງຫມົດ.

Bash ໃນ Linux

script ການສໍາເລັດ Bash ແມ່ນຂຶ້ນກັບຊຸດການສໍາເລັດ bash, ດັ່ງນັ້ນທ່ານຈໍາເປັນຕ້ອງຕິດຕັ້ງມັນກ່ອນ:

$ sudo apt-get install bash-completion

ຫລື:

$ yum install bash-completion

ທ່ານສາມາດທົດສອບວ່າຊຸດໄດ້ຖືກຕິດຕັ້ງຢ່າງສໍາເລັດຜົນໂດຍໃຊ້ຄໍາສັ່ງຕໍ່ໄປນີ້:

$ type _init_completion

ຖ້າອັນນີ້ອອກລະຫັດຟັງຊັນຂອງແກະ, ການຕິດຕັ້ງ bash-completion ຖືກຕິດຕັ້ງຢ່າງຖືກຕ້ອງ. ຖ້າຄໍາສັ່ງໃຫ້ຂໍ້ຜິດພາດ "ບໍ່ພົບ", ທ່ານຈໍາເປັນຕ້ອງເພີ່ມເສັ້ນຕໍ່ໄປນີ້ໃສ່ໄຟລ໌ຂອງທ່ານ ~ / .bashrc:

$ source /usr/share/bash-completion/bash_completion

ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະເພີ່ມເສັ້ນນີ້ໃສ່ໄຟລ໌ ~ / .bashrc ຫຼືບໍ່ແມ່ນຂຶ້ນກັບຕົວຈັດການຊຸດທີ່ທ່ານໃຊ້ໃນການຕິດຕັ້ງ bash-completion. ນີ້ແມ່ນຈໍາເປັນສໍາລັບ APT, ແຕ່ບໍ່ແມ່ນສໍາລັບ YUM.

ຫຼັງຈາກການຕິດຕັ້ງ bash-completion, ທ່ານຈໍາເປັນຕ້ອງ configure ທຸກສິ່ງທຸກຢ່າງເພື່ອໃຫ້ script ສໍາເລັດ kubectl ໄດ້ຖືກເປີດໃຊ້ໃນເຊດຊັນທັງຫມົດ.

ວິທີຫນຶ່ງທີ່ຈະເຮັດຄືການເພີ່ມແຖວຕໍ່ໄປນີ້ໃສ່ໄຟລ໌ ~ / .bashrc:

source <(kubectl completion bash)

ອີກວິທີຫນຶ່ງແມ່ນການເພີ່ມສະຄິບສ່ວນຂະຫຍາຍ kubectl ໃສ່ໄດເລກະທໍລີ /etc/bash_completion.d (ສ້າງ​ມັນ​ຖ້າ​ຫາກ​ວ່າ​ມັນ​ບໍ່​ມີ​)​:

$ kubectl completion bash >/etc/bash_completion.d/kubectl

ສະຄຣິບສ່ວນເສີມທັງໝົດໃນລາຍການ /etc/bash_completion.d ຈະຖືກລວມເຂົ້າໂດຍອັດຕະໂນມັດໃນການສໍາເລັດ bash.

ທັງສອງທາງເລືອກແມ່ນໃຊ້ໄດ້ເທົ່າທຽມກັນ.

ຫຼັງຈາກ restart shell, ຄໍາສັ່ງ kubectl ສໍາເລັດຈະເຮັດວຽກ.

Bash ໃນ MacOS

ໃນ MacOS ການຕິດຕັ້ງແມ່ນສັບສົນກວ່າເລັກນ້ອຍ. ຄວາມຈິງແລ້ວແມ່ນວ່າໂດຍຄ່າເລີ່ມຕົ້ນ, MacOS ໃຊ້ Bash ຮຸ່ນ 3.2, ແລະສະຄິບການຕື່ມຂໍ້ມູນອັດຕະໂນມັດ kubectl ຕ້ອງການສະບັບພາສາ Bash ຢ່າງຫນ້ອຍ 4.1 ແລະບໍ່ໄດ້ເຮັດວຽກຢູ່ໃນ Bash 3.2.

ມີບັນຫາການອະນຸຍາດທີ່ກ່ຽວຂ້ອງກັບການໃຊ້ Bash ເວີຊັນເກົ່າໃນ MacOS. Bash ເວີຊັ່ນ 4 ໄດ້ຮັບອະນຸຍາດພາຍໃຕ້ GPLv3, ເຊິ່ງບໍ່ຮອງຮັບໂດຍ Apple.

ເພື່ອຕັ້ງຄ່າການຕື່ມຂໍ້ມູນອັດຕະໂນມັດ kubectl ໃນ MacOS, ທ່ານຈໍາເປັນຕ້ອງຕິດຕັ້ງ Bash ເວີຊັນຫຼ້າສຸດ. ນອກນັ້ນທ່ານຍັງສາມາດກໍານົດ Bash ທີ່ຖືກປັບປຸງເປັນແກະເລີ່ມຕົ້ນຂອງທ່ານ, ເຊິ່ງຈະຊ່ວຍປະຢັດທ່ານຫຼາຍບັນຫາໃນອະນາຄົດ. ມັນບໍ່ຍາກ, ລາຍລະອຽດແມ່ນໃຫ້ຢູ່ໃນບົດຄວາມ "ກຳລັງອັບເດດ Bash ໃນ MacOS".

ກ່ອນທີ່ຈະສືບຕໍ່, ໃຫ້ແນ່ໃຈວ່າທ່ານກໍາລັງໃຊ້ Bash ຮຸ່ນຫຼ້າສຸດ (ກວດເບິ່ງຜົນຜະລິດ bash --version).

script ການສໍາເລັດ Bash ແຕກຕ່າງກັນໄປຕາມໂຄງການ bash-ສໍາເລັດ, ດັ່ງນັ້ນທ່ານຈໍາເປັນຕ້ອງໄດ້ຕິດຕັ້ງມັນກ່ອນ.

ທ່ານສາມາດຕິດຕັ້ງ bash-completion ໂດຍໃຊ້ Homebrew:

$ brew install bash-completion@2

ມັນເປັນ @2 ຫຍໍ້ມາຈາກ bash-completion version 2. kubectl autocompletion ຕ້ອງການ bash-completion v2, ແລະ bash-completion v2 ຕ້ອງການຢ່າງໜ້ອຍ Bash version 4.1.

ຜົນຜະລິດຄໍາສັ່ງ brew-install ປະກອບມີພາກ Caveats, ເຊິ່ງລະບຸສິ່ງທີ່ຕ້ອງການເພີ່ມໃສ່ໄຟລ໌ ~/.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"

ຢ່າງໃດກໍຕາມ, ຂ້າພະເຈົ້າແນະນໍາໃຫ້ເພີ່ມສາຍເຫຼົ່ານີ້ບໍ່ໃຫ້ ~/.bash_profile, ແລະໃນ ~/.bashrc. ໃນກໍລະນີນີ້, autocompletion ຈະມີບໍ່ພຽງແຕ່ຢູ່ໃນຕົ້ນຕໍ, ແຕ່ຍັງຢູ່ໃນ shells ຄໍາສັ່ງຂອງເດັກນ້ອຍ.

ຫຼັງຈາກ restart shell ຄໍາສັ່ງ, ທ່ານສາມາດກວດສອບການຕິດຕັ້ງທີ່ຖືກຕ້ອງໂດຍໃຊ້ຄໍາສັ່ງຕໍ່ໄປນີ້:

$ type _init_completion

ຖ້າທ່ານເຫັນການທໍາງານຂອງແກະຢູ່ໃນຜົນຜະລິດ, ຫຼັງຈາກນັ້ນທຸກສິ່ງທຸກຢ່າງຈະຖືກຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ.

ຕອນນີ້ພວກເຮົາຕ້ອງການໃຫ້ແນ່ໃຈວ່າ kubectl autocompletion ຖືກເປີດໃຊ້ໃນທຸກເຊດຊັນ.

ວິທີຫນຶ່ງແມ່ນການເພີ່ມເສັ້ນຕໍ່ໄປນີ້ໃສ່ຂອງທ່ານ ~/.bashrc:

source <(kubectl completion bash)

ວິທີທີສອງແມ່ນການເພີ່ມ script ຕື່ມອັດຕະໂນມັດໃສ່ໂຟນເດີ /usr/local/etc/bash_completion.d:

$ kubectl completion bash
>/usr/local/etc/bash_completion.d/kubectl

ວິທີການນີ້ຈະເຮັດວຽກພຽງແຕ່ຖ້າທ່ານຕິດຕັ້ງ bash-completion ໂດຍໃຊ້ Homebrew. ໃນກໍລະນີນີ້, bash-completion ໂຫລດສະຄຣິບທັງໝົດຈາກໄດເລກະທໍລີນີ້.

ຖ້າທ່ານຕິດຕັ້ງ kubectl ໃຊ້ Homebrew, ຫຼັງຈາກນັ້ນບໍ່ຈໍາເປັນຕ້ອງປະຕິບັດຂັ້ນຕອນທີ່ຜ່ານມາ, ເນື່ອງຈາກວ່າ script autocompletion ຈະຖືກຈັດໃສ່ໂດຍອັດຕະໂນມັດໃນໂຟນເດີ. /usr/local/etc/bash_completion.d ໃນລະຫວ່າງການຕິດຕັ້ງ. ໃນກໍລະນີນີ້, kubectl autocompletion ຈະເລີ່ມເຮັດວຽກທັນທີທີ່ທ່ານຕິດຕັ້ງ bash-completion.

ດັ່ງນັ້ນ, ທາງເລືອກທັງຫມົດເຫຼົ່ານີ້ແມ່ນທຽບເທົ່າ.

zsh

scripts ການຕື່ມຂໍ້ມູນອັດຕະໂນມັດສໍາລັບ Zsh ບໍ່ຈໍາເປັນຕ້ອງມີການຂຶ້ນກັບໃດໆ. ສິ່ງທີ່ທ່ານຕ້ອງເຮັດແມ່ນເປີດໃຊ້ພວກມັນເມື່ອທ່ານໂຫລດ shell ຄໍາສັ່ງ.

ທ່ານສາມາດເຮັດໄດ້ໂດຍການເພີ່ມເສັ້ນໃສ່ຂອງທ່ານ ~/.zshrc ໄຟລ໌:

source <(kubectl completion zsh)

ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ໄດ້​ຮັບ​ຄວາມ​ຜິດ​ພາດ​ not found: compdef ຫຼັງຈາກ restart shell ຂອງທ່ານ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ເປີດຟັງຊັນ builtin compdef. ທ່ານສາມາດເປີດໃຊ້ມັນໄດ້ໂດຍການເພີ່ມມັນໃສ່ຈຸດເລີ່ມຕົ້ນຂອງໄຟລ໌ຂອງທ່ານ ~/.zshrc ຕໍ່ໄປນີ້:

autoload -Uz compinit
compinit

2. ເບິ່ງຂໍ້ມູນສະເພາະຂອງຊັບພະຍາກອນຢ່າງໄວວາ

ເມື່ອທ່ານສ້າງຄໍານິຍາມຂອງຊັບພະຍາກອນ YAML, ທ່ານຈໍາເປັນຕ້ອງຮູ້ຂົງເຂດແລະຄວາມຫມາຍຂອງຊັບພະຍາກອນເຫຼົ່ານັ້ນ. ສະຖານທີ່ຫນຶ່ງທີ່ຈະຊອກຫາຂໍ້ມູນນີ້ແມ່ນຢູ່ໃນການອ້າງອິງ API, ເຊິ່ງປະກອບດ້ວຍຂໍ້ມູນສະເພາະສໍາລັບຊັບພະຍາກອນທັງຫມົດ.

ຢ່າງໃດກໍ່ຕາມ, ການປ່ຽນໄປຫາຕົວທ່ອງເວັບທຸກຄັ້ງທີ່ທ່ານຕ້ອງການຄົ້ນຫາບາງສິ່ງບາງຢ່າງແມ່ນບໍ່ສະດວກ. ດັ່ງນັ້ນ kubectl ສະຫນອງຄໍາສັ່ງ kubectl explain, ເຊິ່ງສະແດງໃຫ້ເຫັນສະເພາະຂອງຊັບພະຍາກອນທັງຫມົດໃນ terminal ຂອງທ່ານ.

ຮູບແບບຄໍາສັ່ງແມ່ນດັ່ງຕໍ່ໄປນີ້:

$ kubectl explain resource[.field]...

ຄໍາ​ສັ່ງ​ຈະ​ອອກ​ສະ​ເພາະ​ຂອງ​ຊັບ​ພະ​ຍາ​ກອນ​ທີ່​ຮ້ອງ​ຂໍ​ຫຼື​ພາກ​ສະ​ຫນາມ​ໄດ້​. ຂໍ້ມູນທີ່ສະແດງແມ່ນຄືກັນກັບທີ່ບັນຈຸຢູ່ໃນຄູ່ມື API.

ຕັ້ງແຕ່ຕອນຕົ້ນ kubectl explain ສະແດງໃຫ້ເຫັນພຽງແຕ່ລະດັບທໍາອິດຂອງການຮັງຂອງທົ່ງນາ.

ເບິ່ງວ່າມັນຈະເປັນແນວໃດ ສາມາດຢູ່ທີ່ນີ້.

ທ່ານສາມາດສະແດງຕົ້ນໄມ້ທັງຫມົດຖ້າທ່ານເພີ່ມທາງເລືອກ --recursive:

$ kubectl explain deployment.spec --recursive

ຖ້າທ່ານບໍ່ຮູ້ວ່າຊັບພະຍາກອນໃດທີ່ຕ້ອງການ, ທ່ານສາມາດສະແດງພວກມັນທັງຫມົດດ້ວຍຄໍາສັ່ງຕໍ່ໄປນີ້:

$ kubectl api-resources

ຄໍາສັ່ງນີ້ສະແດງຊື່ຊັບພະຍາກອນໃນຮູບແບບຫຼາຍ, e.g. deployments ແທນທີ່ຈະ deployment. ມັນຍັງສະແດງຊື່ສັ້ນ, ສໍາລັບການຍົກຕົວຢ່າງ deploy, ສໍາລັບຊັບພະຍາກອນເຫຼົ່ານັ້ນທີ່ມີມັນ. ຢ່າກັງວົນກ່ຽວກັບຄວາມແຕກຕ່າງເຫຼົ່ານີ້. ຕົວເລືອກການຕັ້ງຊື່ທັງໝົດນີ້ແມ່ນທຽບເທົ່າກັບ kubectl. ນັ້ນແມ່ນ, ທ່ານສາມາດນໍາໃຊ້ໃດໆຂອງພວກເຂົາສໍາລັບ kubectl explain.

ຄໍາສັ່ງທັງຫມົດຕໍ່ໄປນີ້ແມ່ນທຽບເທົ່າ:

$ kubectl explain deployments.spec
# или
$ kubectl explain deployment.spec
# или        
$ kubectl explain deploy.spec

3. ໃຊ້ຮູບແບບຜົນຜະລິດຖັນແບບກຳນົດເອງ

ຮູບແບບຜົນຜະລິດຄໍາສັ່ງເລີ່ມຕົ້ນ kubectl get:

$ kubectl get pods
NAME                     READY    STATUS    RESTARTS  AGE
engine-544b6b6467-22qr6   1/1     Running     0       78d
engine-544b6b6467-lw5t8   1/1     Running     0       78d
engine-544b6b6467-tvgmg   1/1     Running     0       78d
web-ui-6db964458-8pdw4    1/1     Running     0       78d

ຮູບແບບນີ້ແມ່ນສະດວກ, ແຕ່ມັນມີຈໍານວນຈໍາກັດຂອງຂໍ້ມູນ. ເມື່ອປຽບທຽບກັບຮູບແບບຄໍານິຍາມຊັບພະຍາກອນອັນເຕັມທີ່, ມີພຽງແຕ່ສອງສາມຊ່ອງທີ່ສະແດງຢູ່ທີ່ນີ້.

ໃນກໍລະນີນີ້, ທ່ານສາມາດນໍາໃຊ້ຮູບແບບຜົນຜະລິດຖັນທີ່ກໍາຫນົດເອງ. ມັນອະນຸຍາດໃຫ້ທ່ານສາມາດກໍານົດສິ່ງທີ່ຂໍ້ມູນທີ່ຈະອອກ. ທ່ານສາມາດສະແດງຊ່ອງຂໍ້ມູນໃດໆທີ່ເປັນຖັນແຍກຕ່າງຫາກ.

ການນໍາໃຊ້ຮູບແບບທີ່ກໍາຫນົດເອງແມ່ນຖືກກໍານົດໂດຍໃຊ້ຕົວເລືອກ:

-o custom-columns=<header>:<jsonpath>[,<header>:<jsonpath>]...

ທ່ານສາມາດກໍານົດແຕ່ລະຖັນຜົນຜະລິດເປັນຄູ່ <header>:<jsonpath>ບ່ອນທີ່ <header> ແມ່ນຊື່ຖັນ, ແລະ <jsonpath> — ການ​ສະ​ແດງ​ອອກ​ກໍາ​ນົດ​ພາກ​ສະ​ຫນາມ​ຊັບ​ພະ​ຍາ​ກອນ​.

ຂໍ​ໃຫ້​ເບິ່ງ​ຕົວ​ຢ່າງ​ທີ່​ງ່າຍ​ດາຍ​:

$ kubectl get pods -o custom-columns='NAME:metadata.name'

NAME
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4

ຜົນໄດ້ຮັບປະກອບມີຫນຶ່ງຄໍລໍາທີ່ມີຊື່ຂອງຝັກ.

ການສະແດງອອກທາງເລືອກເລືອກຊື່ຝັກຈາກພາກສະຫນາມ metadata.name. ນີ້ແມ່ນຍ້ອນວ່າຊື່ຂອງຝັກແມ່ນຖືກກໍານົດຢູ່ໃນຊ່ອງໃສ່ຊື່ເດັກ metadata ໃນຄໍາອະທິບາຍຊັບພະຍາກອນຂອງຝັກ. ລາຍລະອຽດເພີ່ມເຕີມສາມາດພົບໄດ້ໃນ ຄູ່ມື API ຫຼືພິມຄໍາສັ່ງ kubectl explain pod.metadata.name.

ຕອນນີ້ໃຫ້ເວົ້າວ່າທ່ານຕ້ອງການເພີ່ມຄໍລໍາເພີ່ມເຕີມໃສ່ຜົນຜະລິດ, ຕົວຢ່າງສະແດງໃຫ້ເຫັນຂໍ້ທີ່ແຕ່ລະ pod ກໍາລັງເຮັດວຽກຢູ່. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານພຽງແຕ່ສາມາດເພີ່ມສະເພາະຖັນທີ່ເຫມາະສົມກັບທາງເລືອກຖັນ custom:

$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,NODE:spec.nodeName'

NAME                       NODE
engine-544b6b6467-22qr6    ip-10-0-80-67.ec2.internal
engine-544b6b6467-lw5t8    ip-10-0-36-80.ec2.internal
engine-544b6b6467-tvgmg    ip-10-0-118-34.ec2.internal
web-ui-6db964458-8pdw4     ip-10-0-118-34.ec2.internal

ການສະແດງອອກເລືອກຊື່ node ຈາກ spec.nodeName — ເມື່ອ​ພອດ​ຖືກ​ມອບ​ໝາຍ​ໃຫ້​ຂໍ້​ມູນ, ຊື່​ຂອງ​ມັນ​ຖືກ​ຂຽນ​ໄວ້​ໃນ​ພາກ​ສະ​ຫນາມ spec.nodeName ຂໍ້ມູນຈໍາເພາະຂອງຊັບພະຍາກອນ pod. ຂໍ້ມູນລາຍລະອຽດເພີ່ມເຕີມສາມາດພົບໄດ້ໃນຜົນຜະລິດ kubectl explain pod.spec.nodeName.

ກະລຸນາຮັບຊາບວ່າຊ່ອງຂໍ້ມູນຂອງ Kubernetes ແມ່ນຕົວພິມນ້ອຍໃຫຍ່.

ທ່ານສາມາດເບິ່ງຊ່ອງຂໍ້ມູນໃດໆທີ່ເປັນຖັນ. ພຽງ​ແຕ່​ກວດ​ສອບ​ການ​ສະ​ເພາະ​ຂອງ​ຊັບ​ພະ​ຍາ​ກອນ​ແລະ​ທົດ​ລອງ​ມັນ​ອອກ​ກັບ​ພາກ​ສະ​ຫນາມ​ໃດ​ຫນຶ່ງ​ທີ່​ທ່ານ​ຕ້ອງ​ການ​.

ແຕ່ທໍາອິດ, ໃຫ້ພວກເຮົາພິຈາລະນາຢ່າງລະອຽດກ່ຽວກັບການສະແດງການຄັດເລືອກພາກສະຫນາມ.

JSONPath Expressions

ການສະແດງອອກສໍາລັບການເລືອກຂົງເຂດຊັບພະຍາກອນແມ່ນອີງໃສ່ JSONPath.

JSONPath ເປັນພາສາສໍາລັບການດຶງຂໍ້ມູນຈາກເອກະສານ JSON. ການເລືອກຊ່ອງຂໍ້ມູນດຽວແມ່ນກໍລະນີການນໍາໃຊ້ທີ່ງ່າຍດາຍທີ່ສຸດສໍາລັບ JSONPath. ລາວມີຫຼາຍ ຄວາມເປັນໄປໄດ້ຫຼາຍຂຶ້ນ, ລວມທັງຕົວເລືອກ, ຕົວກອງແລະອື່ນໆ.

Kubectl ອະທິບາຍສະຫນັບສະຫນູນຈໍານວນຈໍາກັດຂອງຄຸນສົມບັດ JSONPath. ຄວາມເປັນໄປໄດ້ແລະຕົວຢ່າງຂອງການນໍາໃຊ້ຂອງພວກເຂົາແມ່ນໄດ້ອະທິບາຍຂ້າງລຸ່ມນີ້:

# Выбрать все элементы списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[*].image'
# Выбрать специфический элемент списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[0].image'
# Выбрать элементы списка, попадающие под фильтр
$ kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx")].image'
# Выбрать все поля по указанному пути, независимо от их имени
$ kubectl get pods -o custom-columns='DATA:metadata.*'
# Выбрать все поля с указанным именем, вне зависимости от их расположения
$ kubectl get pods -o custom-columns='DATA:..image'

ຕົວປະຕິບັດການ [] ມີຄວາມສໍາຄັນໂດຍສະເພາະ. ຫລາຍຊ່ອງຂໍ້ມູນຂອງ Kubernetes ແມ່ນລາຍຊື່, ແລະຕົວປະຕິບັດການນີ້ອະນຸຍາດໃຫ້ທ່ານເລືອກສະມາຊິກຂອງລາຍຊື່ເຫຼົ່ານັ້ນ. ມັນມັກຈະຖືກໃຊ້ກັບຕົວແທນເຊັ່ນ [*] ເພື່ອເລືອກອົງປະກອບທັງໝົດຂອງລາຍຊື່.

ຕົວຢ່າງຄໍາຮ້ອງສະຫມັກ

ຄວາມເປັນໄປໄດ້ສໍາລັບການນໍາໃຊ້ຮູບແບບຜົນຜະລິດຖັນແບບກໍານົດເອງແມ່ນບໍ່ມີທີ່ສິ້ນສຸດ, ຍ້ອນວ່າທ່ານສາມາດສະແດງຊ່ອງຂໍ້ມູນຫຼືການປະສົມປະສານຂອງຂົງເຂດຊັບພະຍາກອນໃນຜົນໄດ້ຮັບ. ນີ້ແມ່ນບາງແອັບຕົວຢ່າງ, ແຕ່ຮູ້ສຶກວ່າບໍ່ເສຍຄ່າເພື່ອສຳຫຼວດພວກມັນດ້ວຍຕົວທ່ານເອງ ແລະຊອກຫາແອັບພລິເຄຊັນທີ່ເໝາະສົມກັບເຈົ້າ.

1. ກຳລັງສະແດງຮູບບັນຈຸສຳລັບຝັກ:

   $ kubectl get pods 
     -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'
   
   NAME                        IMAGES
   engine-544b6b6467-22qr6     rabbitmq:3.7.8-management,nginx
   engine-544b6b6467-lw5t8     rabbitmq:3.7.8-management,nginx
   engine-544b6b6467-tvgmg     rabbitmq:3.7.8-management,nginx
   web-ui-6db964458-8pdw4      wordpress

   ຄໍາສັ່ງນີ້ສະແດງຊື່ຮູບພາບບັນຈຸສໍາລັບແຕ່ລະ pod.

   ຈື່ໄວ້ວ່າຝັກສາມາດບັນຈຸຫຼາຍຖັງໄດ້, ຫຼັງຈາກນັ້ນຊື່ຮູບພາບຈະຖືກສະແດງຢູ່ໃນແຖວດຽວ, ແຍກດ້ວຍເຄື່ອງໝາຍຈຸດ.

2. ກຳລັງສະແດງເຂດການມີຂອງ node:

   $ kubectl get nodes 
     -o 
   custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain.beta.kubernetes.io/zone'
   
   NAME                          ZONE
   ip-10-0-118-34.ec2.internal   us-east-1b
   ip-10-0-36-80.ec2.internal    us-east-1a
   ip-10-0-80-67.ec2.internal    us-east-1b

   ຄໍາສັ່ງນີ້ເປັນປະໂຫຍດຖ້າກຸ່ມຂອງທ່ານຖືກໂຮດຢູ່ໃນຄລາວສາທາລະນະ. ມັນສະແດງເຂດທີ່ມີໃຫ້ສໍາລັບແຕ່ລະ node.

   ເຂດການມີຢູ່ແມ່ນແນວຄວາມຄິດຂອງຄລາວທີ່ຈຳກັດເຂດການຈຳລອງເປັນເຂດພູມສາດ.

   ເຂດທີ່ມີຢູ່ສໍາລັບແຕ່ລະ node ແມ່ນໄດ້ຮັບໂດຍຜ່ານປ້າຍພິເສດ - failure-domain.beta.kubernetes.io/zone. ຖ້າກຸ່ມກໍາລັງເຮັດວຽກຢູ່ໃນຄລາວສາທາລະນະ, ປ້າຍຊື່ນີ້ຈະຖືກສ້າງຂື້ນໂດຍອັດຕະໂນມັດແລະເຕັມໄປດ້ວຍຊື່ຂອງເຂດທີ່ມີສໍາລັບແຕ່ລະ node.

   ປ້າຍກຳກັບບໍ່ແມ່ນສ່ວນໜຶ່ງຂອງຂໍ້ມູນສະເພາະຂອງຊັບພະຍາກອນ Kubernetes, ດັ່ງນັ້ນທ່ານຈະບໍ່ພົບຂໍ້ມູນກ່ຽວກັບພວກມັນໃນ ຄູ່ມື API. ຢ່າງໃດກໍຕາມ, ພວກເຂົາສາມາດເຫັນໄດ້ (ຄືກັບປ້າຍຊື່ອື່ນໆ) ຖ້າທ່ານຮ້ອງຂໍຂໍ້ມູນກ່ຽວກັບ nodes ໃນຮູບແບບ YAML ຫຼື JSON:

   $ kubectl get nodes -o yaml
   # или
   $ kubectl get nodes -o json

   ນີ້ແມ່ນວິທີທີ່ດີທີ່ຈະຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບຊັບພະຍາກອນ, ນອກເຫນືອຈາກການຮຽນຮູ້ສະເພາະຂອງຊັບພະຍາກອນ.

4. ສະຫຼັບລະຫວ່າງກຸ່ມ ແລະ namespaces ໄດ້ຢ່າງງ່າຍດາຍ

ເມື່ອ kubectl ຮ້ອງຂໍໃຫ້ Kubernetes API, ທໍາອິດມັນຈະອ່ານໄຟລ໌ kubeconfig ເພື່ອໃຫ້ໄດ້ຮັບພາລາມິເຕີທີ່ຈໍາເປັນທັງຫມົດສໍາລັບການເຊື່ອມຕໍ່.

ໂດຍຄ່າເລີ່ມຕົ້ນໄຟລ໌ kubeconfig ແມ່ນ ~/.kube/config. ໂດຍປົກກະຕິໄຟລ໌ນີ້ຖືກສ້າງຂື້ນຫຼືປັບປຸງໂດຍຄໍາສັ່ງພິເສດ.

ເມື່ອທ່ານເຮັດວຽກກັບຫຼາຍກຸ່ມ, ໄຟລ໌ kubeconfig ຂອງທ່ານມີການຕັ້ງຄ່າເພື່ອເຊື່ອມຕໍ່ກັບກຸ່ມທັງໝົດເຫຼົ່ານັ້ນ. ທ່ານຕ້ອງການວິທີການບອກຄໍາສັ່ງ kubectl ທີ່ກຸ່ມທີ່ທ່ານກໍາລັງເຮັດວຽກກັບ.

ພາຍໃນກຸ່ມ, ທ່ານສາມາດສ້າງ namespaces ຫຼາຍອັນ—ປະເພດຂອງກຸ່ມ virtual ພາຍໃນກຸ່ມທາງກາຍະພາບ. Kubectl ຍັງກໍານົດວ່າຈະໃຊ້ namespace ໃດໂດຍອີງໃສ່ໄຟລ໌ kubeconfig. ນີ້ຫມາຍຄວາມວ່າທ່ານຍັງຕ້ອງການວິທີການບອກຄໍາສັ່ງ kubectl ວ່າ namespace ທີ່ຈະເຮັດວຽກກັບ.

ໃນບົດນີ້ພວກເຮົາຈະອະທິບາຍວິທີການເຮັດວຽກແລະວິທີການເຮັດໃຫ້ມັນເຮັດວຽກຢ່າງມີປະສິດທິພາບ.

ກະລຸນາຮັບຊາບວ່າທ່ານອາດມີໄຟລ໌ kubeconfig ຫຼາຍລາຍການຢູ່ໃນຕົວແປສະພາບແວດລ້ອມ KUBECONFIG. ໃນກໍລະນີນີ້, ໄຟລ໌ທັງຫມົດເຫຼົ່ານີ້ຈະຖືກລວມເຂົ້າກັນເປັນການຕັ້ງຄ່າທົ່ວໄປດຽວໃນເວລາແລ່ນ. ນອກນັ້ນທ່ານຍັງສາມາດປ່ຽນໄຟລ໌ kubeconfig ເລີ່ມຕົ້ນໂດຍການແລ່ນ kubectl ກັບພາລາມິເຕີ --kubeconfig. ເບິ່ງ ເອກະສານທາງການ.

kubeconfig ໄຟລ໌

ມາເບິ່ງກັນວ່າໄຟລ໌ kubeconfig ມີຫຍັງແດ່:

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ໄຟລ໌ kubeconfig ມີຊຸດຂອງສະພາບການ. ບໍລິບົດປະກອບດ້ວຍສາມອົງປະກອບ:

• Cluster — API URL ຂອງ cluster server.
• ຜູ້ໃຊ້ - user authentication credentials in the cluster.
• Namespace - ຊ່ອງຊື່ທີ່ໃຊ້ໃນເວລາເຂົ້າຮ່ວມກຸ່ມ.

ໃນການປະຕິບັດ, ພວກເຂົາມັກຈະໃຊ້ຫນຶ່ງບໍລິບົດຕໍ່ກຸ່ມໃນ kubeconfig ຂອງພວກເຂົາ. ຢ່າງໃດກໍຕາມ, ທ່ານສາມາດມີຫຼາຍບໍລິບົດຕໍ່ກຸ່ມ, ແຕກຕ່າງກັນໂດຍຜູ້ໃຊ້ຫຼື namespace. ແນວໃດກໍ່ຕາມ, ການຕັ້ງຄ່າຫຼາຍບໍລິບົດນີ້ແມ່ນເລື່ອງແປກ, ສະນັ້ນໂດຍປົກກະຕິແລ້ວມີການສ້າງແຜນທີ່ແບບໜຶ່ງຕໍ່ໜຶ່ງລະຫວ່າງກຸ່ມ ແລະ ບໍລິບົດ.

ໃນເວລາໃດກໍ່ຕາມ, ຫນຶ່ງໃນສະພາບການແມ່ນປະຈຸບັນ:

ເມື່ອ kubectl ອ່ານໄຟລ໌ການຕັ້ງຄ່າ, ມັນສະເຫມີເອົາຂໍ້ມູນຈາກສະພາບການໃນປະຈຸບັນ. ໃນຕົວຢ່າງຂ້າງເທິງ, kubectl ຈະເຊື່ອມຕໍ່ກັບກຸ່ມ Hare.

ດັ່ງນັ້ນ, ເພື່ອປ່ຽນໄປຫາກຸ່ມອື່ນ, ທ່ານຈໍາເປັນຕ້ອງປ່ຽນສະພາບການໃນປະຈຸບັນຢູ່ໃນໄຟລ໌ kubeconfig:

ໃນປັດຈຸບັນ kubectl ຈະເຊື່ອມຕໍ່ກັບກຸ່ມ Fox.

ເພື່ອປ່ຽນເປັນ namespace ທີ່ແຕກຕ່າງກັນໃນກຸ່ມດຽວກັນ, ທ່ານຈໍາເປັນຕ້ອງປ່ຽນຄ່າຂອງອົງປະກອບ namespace ສໍາລັບສະພາບການປະຈຸບັນ:

ໃນຕົວຢ່າງຂ້າງເທິງ, kubectl ຈະໃຊ້ Prod namespace ຂອງ Fox cluster (ກ່ອນໜ້ານີ້ໄດ້ມີການຕັ້ງຊື່ Test namespace).

ໃຫ້ສັງເກດວ່າ kubectl ຍັງສະຫນອງທາງເລືອກ --cluster, --user, --namespace и --context, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານຂຽນທັບອົງປະກອບສ່ວນບຸກຄົນແລະສະພາບການປະຈຸບັນຂອງມັນເອງ, ໂດຍບໍ່ຄໍານຶງເຖິງສິ່ງທີ່ຖືກກໍານົດໄວ້ໃນ kubeconfig. ເບິ່ງ kubectl options.

ໃນທາງທິດສະດີ, ທ່ານສາມາດປ່ຽນການຕັ້ງຄ່າດ້ວຍຕົນເອງໃນ kubeconfig. ແຕ່ມັນບໍ່ສະດວກ. ເພື່ອເຮັດໃຫ້ການດໍາເນີນງານເຫຼົ່ານີ້ງ່າຍຂຶ້ນ, ມີອຸປະກອນຕ່າງໆທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດປ່ຽນພາລາມິເຕີໂດຍອັດຕະໂນມັດ.

ໃຊ້ kubectx

ຜົນປະໂຫຍດທີ່ນິຍົມຫຼາຍສໍາລັບການປ່ຽນລະຫວ່າງກຸ່ມແລະ namespaces.

ຜົນປະໂຫຍດສະຫນອງຄໍາສັ່ງ kubectx и kubens ເພື່ອປ່ຽນບໍລິບົດປັດຈຸບັນ ແລະ namespace ຕາມລໍາດັບ.

ດັ່ງທີ່ໄດ້ກ່າວມາ, ການປ່ຽນແປງບໍລິບົດປະຈຸບັນຫມາຍເຖິງການປ່ຽນແປງກຸ່ມຖ້າຫາກວ່າທ່ານມີພຽງແຕ່ຫນຶ່ງບໍລິບົດຕໍ່ກຸ່ມ.

ນີ້ແມ່ນຕົວຢ່າງຂອງການແລ່ນຄໍາສັ່ງເຫຼົ່ານີ້:

ໂດຍພື້ນຖານແລ້ວ, ຄໍາສັ່ງເຫຼົ່ານີ້ພຽງແຕ່ແກ້ໄຂໄຟລ໌ kubeconfig ດັ່ງທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ.

ການຕິດຕັ້ງ kubectx, ປະຕິບັດຕາມຄໍາແນະນໍາກ່ຽວກັບ Github.

ທັງສອງຄໍາສັ່ງສະຫນັບສະຫນູນການຕື່ມຂໍ້ມູນອັດຕະໂນມັດຂອງ context ແລະ namespace ຊື່, ເຊິ່ງລົບລ້າງຄວາມຕ້ອງການທີ່ຈະພິມໃຫ້ເຂົາເຈົ້າຫມົດ. ຄໍາແນະນໍາສໍາລັບການຕັ້ງຄ່າການຕື່ມຂໍ້ມູນອັດຕະໂນມັດ ທີ່ນີ້.

ລັກສະນະທີ່ເປັນປະໂຫຍດອີກອັນຫນຶ່ງ kubectx ມັນ​ເປັນ ຮູບແບບການໂຕ້ຕອບ. ມັນເຮັດວຽກຮ່ວມກັນກັບຜົນປະໂຫຍດ fzf, ເຊິ່ງຕ້ອງໄດ້ຮັບການຕິດຕັ້ງແຍກຕ່າງຫາກ. ການຕິດຕັ້ງ fzf ອັດຕະໂນມັດເຮັດໃຫ້ຮູບແບບການໂຕ້ຕອບມີຢູ່ໃນ kubectx. ການໂຕ້ຕອບ, ທ່ານສາມາດເລືອກບໍລິບົດແລະ namespace ໂດຍຜ່ານການໂຕ້ຕອບການຊອກຫາຟຣີທີ່ສະຫນອງໂດຍ fzf.

ການນໍາໃຊ້ນາມແຝງ shell

ທ່ານບໍ່ຕ້ອງການເຄື່ອງມືແຍກຕ່າງຫາກເພື່ອປ່ຽນສະພາບການແລະ namespace ໃນປັດຈຸບັນເພາະວ່າ kubectl ຍັງສະຫນອງຄໍາສັ່ງສໍາລັບການນີ້. ແມ່ນແລ້ວ, ທີມງານ kubectl config ສະຫນອງຄໍາສັ່ງຍ່ອຍສໍາລັບການດັດແກ້ໄຟລ໌ kubeconfig.

ຕໍ່ໄປນີ້ແມ່ນບາງສ່ວນຂອງພວກເຂົາ:

• kubectl config get-contexts: ສະແດງບໍລິບົດທັງໝົດ;
• kubectl config current-context: ໄດ້ຮັບສະພາບການປະຈຸບັນ;
• kubectl config use-context: ປ່ຽນແປງສະພາບການປະຈຸບັນ;
• kubectl config set-context: ປ່ຽນອົງປະກອບບໍລິບົດ.

ຢ່າງໃດກໍ່ຕາມ, ການນໍາໃຊ້ຄໍາສັ່ງເຫຼົ່ານີ້ໂດຍກົງແມ່ນບໍ່ສະດວກຫຼາຍເພາະວ່າພວກມັນຍາວ. ທ່ານສາມາດສ້າງນາມແຝງແກະສໍາລັບພວກມັນທີ່ງ່າຍຕໍ່ການປະຕິບັດ.

ຂ້ອຍສ້າງຊຸດຂອງນາມແຝງໂດຍອີງໃສ່ຄໍາສັ່ງເຫຼົ່ານີ້ທີ່ສະຫນອງຫນ້າທີ່ຄ້າຍຄືກັບ kubectx. ທີ່ນີ້ທ່ານສາມາດເບິ່ງພວກເຂົາຢູ່ໃນການປະຕິບັດ:

ໃຫ້ສັງເກດວ່ານາມແຝງໃຊ້ fzf ເພື່ອສະຫນອງການໂຕ້ຕອບການຊອກຫາຟຣີແບບໂຕ້ຕອບ (ເຊັ່ນ: ຮູບແບບໂຕ້ຕອບຂອງ kubectx). ນີ້ຫມາຍຄວາມວ່າທ່ານຕ້ອງການ ຕິດຕັ້ງ fzfເພື່ອໃຊ້ນາມແຝງເຫຼົ່ານີ້.

ນີ້ແມ່ນຄໍານິຍາມຂອງນາມແຝງຂອງຕົນເອງ:

# Получить текущий контекст
alias krc='kubectl config current-context'
# Список всех контекстов
alias klc='kubectl config get-contexts -o name | sed "s/^/  /;|^  $(krc)$|s/ /*/"'
# Изменить текущий контекст
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'

# Получить текущее пространство имен
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print $5}" | sed "s/^$/default/"'
# Список всех пространств имен
alias kln='kubectl get -o name ns | sed "s|^.*/|  |;|^  $(krn)$|s/ /*/"'
# Изменить текущее пространство имен
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'

ເພື່ອກໍານົດນາມແຝງເຫຼົ່ານີ້, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມຄໍານິຍາມຂ້າງເທິງໃສ່ໄຟລ໌ຂອງທ່ານ ~/.bashrc ຫຼື ~/.zshrc ແລະ reboot shell ຂອງທ່ານ.

ການນໍາໃຊ້ plugins

Kubectl ອະນຸຍາດໃຫ້ທ່ານສາມາດໂຫລດ plugins ທີ່ຖືກປະຕິບັດໃນແບບດຽວກັນກັບຄໍາສັ່ງພື້ນຖານ. ຕົວຢ່າງເຊັ່ນ, ທ່ານສາມາດຕິດຕັ້ງ plugin kubectl-foo ແລະດໍາເນີນການໂດຍການປະຕິບັດຄໍາສັ່ງ kubectl foo.

ມັນຈະເປັນການສະດວກໃນການປ່ຽນແປງບໍລິບົດແລະ namespace ໃນທາງນີ້, ສໍາລັບການຍົກຕົວຢ່າງໂດຍການແລ່ນ kubectl ctx ການ​ປ່ຽນ​ແປງ​ສະ​ພາບ​ການ​ແລະ​ kubectl ns ເພື່ອປ່ຽນ namespace.

ຂ້າພະເຈົ້າໄດ້ຂຽນສອງ plugins ທີ່ເຮັດສິ່ງນີ້:

• kubectl-ctx
• kubectl-ns

ການເຮັດວຽກຂອງ plugins ແມ່ນອີງໃສ່ນາມແຝງຈາກພາກສ່ວນທີ່ຜ່ານມາ.

ນີ້ແມ່ນວິທີທີ່ພວກເຂົາເຮັດວຽກ:

ໃຫ້ສັງເກດວ່າ plugins ໃຊ້ fzf ເພື່ອສະຫນອງການໂຕ້ຕອບການຊອກຫາຟຣີແບບໂຕ້ຕອບ (ເຊັ່ນ: ຮູບແບບໂຕ້ຕອບຂອງ kubectx). ນີ້ຫມາຍຄວາມວ່າທ່ານຕ້ອງການ ຕິດຕັ້ງ fzfເພື່ອໃຊ້ນາມແຝງເຫຼົ່ານີ້.

ເພື່ອຕິດຕັ້ງ plugins, ທ່ານຈໍາເປັນຕ້ອງດາວໂຫລດ shell scripts ທີ່ມີຊື່ kubectl-ctx и kubectl-ns ໄປຫາໄດເລກະທໍລີໃດໆໃນຕົວແປ PATH ຂອງທ່ານແລະເຮັດໃຫ້ພວກເຂົາສາມາດປະຕິບັດໄດ້ດ້ວຍຕົວຢ່າງເຊັ່ນ. chmod +x. ທັນທີຫຼັງຈາກນີ້, ທ່ານຈະສາມາດນໍາໃຊ້ kubectl ctx и kubectl ns.

5. ຫຼຸດຜ່ອນການປ້ອນຂໍ້ມູນດ້ວຍ autoaliases

ນາມແຝງ Shell ເປັນວິທີທີ່ດີທີ່ຈະເລັ່ງການປ້ອນຂໍ້ມູນ. ໂຄງການ kubectl-aliases ມີປະມານ 800 ທາງລັດສໍາລັບຄໍາສັ່ງ kubectl ພື້ນຖານ.

ເຈົ້າອາດຈະສົງໄສ - ເຈົ້າຈື່ 800 ນາມແຝງໄດ້ແນວໃດ? ແຕ່ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງຈື່ພວກມັນທັງ ໝົດ, ເພາະວ່າພວກມັນຖືກສ້າງຂື້ນຕາມໂຄງການທີ່ງ່າຍດາຍ, ເຊິ່ງມີຢູ່ຂ້າງລຸ່ມນີ້:

ຕົວຢ່າງ:

1. kgpooyaml - kubectl ຮັບຝັກ oyaml
2. ksysgsvcw — kubectl -n kube-system get svc w
3. ksysrmcm -kubectl -n kube-system rm cm
4. kgdepallsl - kubectl ໄດ້​ຮັບ​ການ​ນໍາ​ໃຊ້​ທັງ​ຫມົດ sl

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ນາມແຝງແມ່ນປະກອບດ້ວຍອົງປະກອບ, ແຕ່ລະອັນເປັນຕົວແທນຂອງອົງປະກອບສະເພາະຂອງຄໍາສັ່ງ kubectl. ແຕ່ລະ alias ສາມາດມີອົງປະກອບຫນຶ່ງສໍາລັບຄໍາສັ່ງພື້ນຖານ, ການດໍາເນີນງານ, ແລະຊັບພະຍາກອນ, ແລະອົງປະກອບຫຼາຍສໍາລັບພາລາມິເຕີ. ທ່ານພຽງແຕ່ "ຕື່ມ" ອົງປະກອບເຫຼົ່ານີ້ຈາກຊ້າຍຫາຂວາຕາມແຜນວາດຂ້າງເທິງ.

ແຜນວາດລາຍລະອຽດປະຈຸບັນຢູ່ທີ່ GitHub. ຢູ່ທີ່ນັ້ນເຈົ້າຍັງສາມາດຊອກຫາໄດ້ ບັນຊີລາຍຊື່ເຕັມຂອງນາມແຝງ.

ຕົວຢ່າງ, alias kgpooyamlall ແມ່ນທຽບເທົ່າກັບຄໍາສັ່ງ kubectl get pods -o yaml --all-namespaces.

ຄໍາສັ່ງທີ່ກ່ຽວຂ້ອງຂອງທາງເລືອກແມ່ນບໍ່ສໍາຄັນ: ຄໍາສັ່ງ kgpooyamlall ເທົ່າກັບຄໍາສັ່ງ kgpoalloyaml.

ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງໃຊ້ສ່ວນປະກອບທັງ ໝົດ ເປັນນາມແຝງ. ຍົກ​ຕົວ​ຢ່າງ k, kg, klo, ksys, kgpo ຍັງສາມາດຖືກນໍາໃຊ້. ຍິ່ງໄປກວ່ານັ້ນ, ທ່ານສາມາດສົມທົບນາມແຝງແລະຄໍາສັ່ງປົກກະຕິຫຼືທາງເລືອກໃນເສັ້ນຄໍາສັ່ງ:

ຕົວຢ່າງ:

1. ແທນທີ່ຈະ kubectl proxy ທ່ານສາມາດຂຽນ k proxy.
2. ແທນທີ່ຈະ kubectl get roles ທ່ານສາມາດຂຽນ kg roles (ປະຈຸບັນບໍ່ມີນາມແຝງສໍາລັບຊັບພະຍາກອນຂອງ Roles).
3. ເພື່ອໃຫ້ໄດ້ຮັບຂໍ້ມູນສໍາລັບຝັກສະເພາະ, ທ່ານສາມາດນໍາໃຊ້ຄໍາສັ່ງ kgpo my-pod — kubectl get pod my-pod.

ກະລຸນາຮັບຊາບວ່າບາງນາມແຝງຕ້ອງການການໂຕ້ຖຽງແຖວຄຳສັ່ງ. ຕົວຢ່າງ, ນາມແຝງ kgpol ຫມາຍຄວາມວ່າ kubectl get pods -l. ທາງເລືອກ -l ຮຽກຮ້ອງໃຫ້ມີການໂຕ້ຖຽງ - ສະເພາະປ້າຍຊື່. ຖ້າທ່ານໃຊ້ນາມແຝງ, ມັນຈະເບິ່ງຄືວ່າ kgpol app=ui.

ເນື່ອງຈາກວ່າບາງນາມແຝງຕ້ອງການການໂຕ້ຖຽງ, ນາມແຝງ a, f, ແລະ l ຈະຕ້ອງໃຊ້ສຸດທ້າຍ.

ໂດຍທົ່ວໄປ, ເມື່ອທ່ານໄດ້ຮັບການວາງສາຍຂອງໂຄງການນີ້, ທ່ານສາມາດ intuitively ເອົານາມແຝງຈາກຄໍາສັ່ງທີ່ທ່ານຕ້ອງການປະຕິບັດແລະປະຫຍັດເວລາພິມຫຼາຍ.

ການຕິດຕັ້ງ

ເພື່ອຕິດຕັ້ງ kubectl-aliases, ທ່ານຈໍາເປັນຕ້ອງໄດ້ດາວໂຫລດໄຟລ໌ .kubectl_aliases ຈາກ GitHub ແລະລວມມັນຢູ່ໃນໄຟລ໌ ~/.bashrc ຫຼື ~/.zshrc:

source ~/.kubectl_aliases

ການຕື່ມຂໍ້ມູນອັດຕະໂນມັດ

ດັ່ງທີ່ພວກເຮົາໄດ້ກ່າວມາກ່ອນ, ທ່ານມັກຈະເພີ່ມຄໍາສັບເພີ່ມເຕີມໃສ່ນາມແຝງຢູ່ໃນເສັ້ນຄໍາສັ່ງ. ຍົກ​ຕົວ​ຢ່າງ:

$ kgpooyaml test-pod-d4b77b989

ຖ້າທ່ານໃຊ້ການສໍາເລັດຄໍາສັ່ງ kubectl, ທ່ານອາດຈະໃຊ້ການຕື່ມຂໍ້ມູນອັດຕະໂນມັດສໍາລັບສິ່ງຕ່າງໆເຊັ່ນຊື່ຊັບພະຍາກອນ. ແຕ່ນີ້ສາມາດເຮັດໄດ້ເມື່ອນາມແຝງຖືກໃຊ້ບໍ?

ນີ້ແມ່ນຄໍາຖາມທີ່ສໍາຄັນຫຼາຍເພາະວ່າຖ້າການຕື່ມຂໍ້ມູນອັດຕະໂນມັດບໍ່ໄດ້ຜົນ, ທ່ານຈະສູນເສຍຜົນປະໂຫຍດບາງຢ່າງຂອງນາມແຝງ.

ຄໍາຕອບແມ່ນຂຶ້ນກັບວ່າ Shell ທີ່ທ່ານກໍາລັງໃຊ້:

1. ສໍາລັບ Zsh, ການສໍາເລັດນາມແຝງເຮັດວຽກອອກຈາກກ່ອງ.
2. ສໍາລັບ Bash, ແຕ່ຫນ້າເສຍດາຍ, ບາງວຽກຈໍາເປັນຕ້ອງໄດ້ຮັບການຕື່ມຂໍ້ມູນອັດຕະໂນມັດເພື່ອເຮັດວຽກ.

ເປີດໃຊ້ການຕື່ມຂໍ້ມູນອັດຕະໂນມັດສໍາລັບນາມແຝງໃນ Bash

ບັນຫາກັບ Bash ແມ່ນວ່າມັນພະຍາຍາມສໍາເລັດ (ທຸກໆຄັ້ງທີ່ທ່ານກົດ Tab) alias, ບໍ່ແມ່ນຄໍາສັ່ງທີ່ alias ຫມາຍເຖິງ (ເຊັ່ນ Zsh ເຮັດ, ສໍາລັບການຍົກຕົວຢ່າງ). ເນື່ອງຈາກທ່ານບໍ່ມີສະຄຣິບສໍາເລັດສໍາລັບ 800 ນາມແຝງ, ການຕື່ມຂໍ້ມູນອັດຕະໂນມັດຈະບໍ່ເຮັດວຽກ.

ໂຄງການ ນາມແຝງ ສະຫນອງການແກ້ໄຂທົ່ວໄປຕໍ່ກັບບັນຫານີ້. ມັນເຊື່ອມຕໍ່ກັບກົນໄກການສໍາເລັດສໍາລັບນາມແຝງ, ພາຍໃນຂະຫຍາຍນາມແຝງໄປຫາຄໍາສັ່ງ, ແລະສົ່ງຄືນທາງເລືອກການສໍາເລັດສໍາລັບຄໍາສັ່ງທີ່ສໍາເລັດ. ນີ້ຫມາຍຄວາມວ່າ padding ສໍາລັບ alias ປະຕິບັດຄືກັນກັບຄໍາສັ່ງຢ່າງເຕັມທີ່.

ໃນຕໍ່ໄປນີ້, ທໍາອິດຂ້ອຍຈະອະທິບາຍວິທີການຕິດຕັ້ງນາມແຝງທີ່ສົມບູນແລະຫຼັງຈາກນັ້ນວິທີການກໍານົດມັນເພື່ອໃຫ້ສໍາເລັດສໍາລັບນາມແຝງ kubectl ທັງຫມົດ.

ການຕິດຕັ້ງນາມແຝງທີ່ສົມບູນ

ກ່ອນອື່ນ ໝົດ, ສົມບູນນາມແຝງແມ່ນຂຶ້ນກັບ bash-ສໍາເລັດ. ດັ່ງນັ້ນ, ກ່ອນທີ່ຈະຕິດຕັ້ງ alias ສໍາເລັດ, ທ່ານຈໍາເປັນຕ້ອງໃຫ້ແນ່ໃຈວ່າການຕິດຕັ້ງ bash-completion. ຄໍາແນະນໍາການຕິດຕັ້ງໄດ້ຖືກສະຫນອງໃຫ້ກ່ອນຫນ້ານີ້ສໍາລັບ Linux ແລະ MacOS.

ຫມາຍເຫດສໍາຄັນສໍາລັບຜູ້ໃຊ້ macOS: ເຊັ່ນດຽວກັບ script kubectl autocompletion, complete-alias ບໍ່ເຮັດວຽກກັບ Bash 3.2, ເຊິ່ງເປັນຄ່າເລີ່ມຕົ້ນໃນ MacOS. ໂດຍສະເພາະ, complete-alias ແມ່ນຂຶ້ນກັບ bash-completion v2 (brew install bash-completion@2), ເຊິ່ງຕ້ອງການຢ່າງຫນ້ອຍ Bash 4.1. ນີ້ຫມາຍຄວາມວ່າເພື່ອໃຊ້ນາມແຝງທີ່ສົມບູນໃນ MacOS ທ່ານຈໍາເປັນຕ້ອງຕິດຕັ້ງ Bash ຮຸ່ນໃຫມ່.

ທ່ານຈໍາເປັນຕ້ອງໄດ້ດາວໂຫລດ script bash_completion.sh ຈາກນັ້ນ ຄັງເກັບ GitHub ແລະລວມມັນຢູ່ໃນໄຟລ໌ຂອງທ່ານ ~/.bashrc:

source ~/bash_completion.sh

ຫຼັງຈາກ rebooting shell, alias ສົມບູນຈະຖືກຕິດຕັ້ງຢ່າງເຕັມສ່ວນ.

ເປີດໃຊ້ການຕື່ມຂໍ້ມູນອັດຕະໂນມັດສຳລັບນາມແຝງ kubectl

ທາງດ້ານເຕັກນິກທີ່ສົມບູນ-alias ໃຫ້ຟັງຊັນ wrapper _complete_alias. ຟັງຊັນນີ້ກວດເບິ່ງນາມແຝງ ແລະສົ່ງຄືນຄໍາຊີ້ບອກການສໍາເລັດສໍາລັບຄໍາສັ່ງ alias.

ເພື່ອເຊື່ອມໂຍງຟັງຊັນທີ່ມີນາມແຝງສະເພາະ, ທ່ານຈໍາເປັນຕ້ອງໃຊ້ກົນໄກ Bash ທີ່ສ້າງມາ ສົມບູນ, ການ​ຕິດ​ຕັ້ງ​ _complete_alias ເປັນຫນ້າທີ່ສໍາເລັດນາມແຝງ.

ຕົວຢ່າງ, ໃຫ້ເຮົາເອົາ alias k, ເຊິ່ງຫຍໍ້ມາຈາກຄໍາສັ່ງ kubectl. ການຕິດຕັ້ງ _complete_alias ໃນຖານະເປັນຫນ້າທີ່ເສີມສໍາລັບນາມແຝງນີ້, ທ່ານຄວນດໍາເນີນການຄໍາສັ່ງຕໍ່ໄປນີ້:

$ complete -F _complete_alias k

ຜົນໄດ້ຮັບຂອງສິ່ງນີ້ແມ່ນວ່າທຸກຄັ້ງທີ່ທ່ານຕື່ມຂໍ້ມູນໃສ່ນາມແຝງ k ອັດຕະໂນມັດ, ຟັງຊັນຖືກເອີ້ນ _complete_alias, ເຊິ່ງກວດເບິ່ງນາມແຝງແລະສົ່ງຄືນຄໍາແນະນໍາການສໍາເລັດສໍາລັບຄໍາສັ່ງ kubectl.

ເປັນຕົວຢ່າງທີສອງ, ໃຫ້ເຮົາໃຊ້ນາມແຝງ kg, ເຊິ່ງຫມາຍເຖິງ kubectl get:

$ complete -F _complete_alias kg

ຄືກັນກັບໃນຕົວຢ່າງທີ່ຜ່ານມາ, ເມື່ອທ່ານຕື່ມກິໂລອັດຕະໂນມັດ, ທ່ານໄດ້ຮັບຄໍາແນະນໍາການສໍາເລັດດຽວກັນທີ່ທ່ານຈະໄດ້ຮັບ. kubectl get.

ຈົ່ງຈື່ໄວ້ວ່າທ່ານສາມາດນໍາໃຊ້ນາມແຝງທີ່ສົມບູນສໍາລັບນາມແຝງໃດໆໃນລະບົບຂອງທ່ານ.

ດັ່ງນັ້ນ, ເພື່ອເປີດໃຊ້ການຕື່ມຂໍ້ມູນອັດຕະໂນມັດສໍາລັບນາມແຝງ kubectl ທັງຫມົດ, ທ່ານຈໍາເປັນຕ້ອງດໍາເນີນການຄໍາສັ່ງຂ້າງເທິງນີ້ສໍາລັບແຕ່ລະຄົນ. snippet ຕໍ່ໄປນີ້ເຮັດໄດ້ແນ່ນອນ, ສະຫນອງໃຫ້ທ່ານໄດ້ຕັ້ງ kubectl-aliases ເປັນ ~/.kubectl-aliases:

for _a in $(sed '/^alias /!d;s/^alias //;s/=.*$//' ~/.kubectl_aliases); 
do
  complete -F _complete_alias "$_a"
done

ຊິ້ນສ່ວນຂອງລະຫັດນີ້ຕ້ອງໄດ້ຮັບການວາງໄວ້ໃນຂອງທ່ານ ~/.bashrc, restart shell ຄໍາສັ່ງແລະການຕື່ມຂໍ້ມູນອັດຕະໂນມັດຈະສາມາດໃຊ້ໄດ້ສໍາລັບທັງຫມົດ 800 kubectl aliases.

6. ຂະຫຍາຍ kubectl ກັບ plugins

ເລີ່ມຕົ້ນຈາກ ຮຸ່ນ 1.12, kubectl ສະຫນັບສະຫນູນ ກົນໄກ plugin, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສາມາດຂະຫຍາຍຫນ້າທີ່ຂອງຕົນດ້ວຍຄໍາສັ່ງເພີ່ມເຕີມ.

ຖ້າທ່ານຄຸ້ນເຄີຍກັບ Git ກົນໄກ plugin, ຫຼັງຈາກນັ້ນ, plugins kubectl ຖືກສ້າງຂຶ້ນໃນຫຼັກການດຽວກັນ.

ໃນບົດນີ້, ພວກເຮົາຈະກວມເອົາວິທີການຕິດຕັ້ງ plugins, ບ່ອນທີ່ຊອກຫາພວກມັນ, ແລະວິທີການສ້າງ plugins ຂອງທ່ານເອງ.

ການຕິດຕັ້ງປລັກອິນ

plugins Kubectl ຖືກແຈກຢາຍເປັນໄຟລ໌ທີ່ປະຕິບັດໄດ້ງ່າຍດາຍທີ່ມີຊື່ເຊັ່ນ kubectl-x. ຄຳນຳໜ້າ kubectl- ແມ່ນຕ້ອງການ, ຕິດຕາມດ້ວຍຄໍາສັ່ງຍ່ອຍ kubectl ໃຫມ່ທີ່ອະນຸຍາດໃຫ້ທ່ານໂທຫາ plugin ໄດ້.

ຕົວຢ່າງ, plugin hello ຈະຖືກແຈກຢາຍເປັນໄຟລ໌ທີ່ເອີ້ນວ່າ kubectl-hello.

ເພື່ອຕິດຕັ້ງ plugin, ທ່ານຈໍາເປັນຕ້ອງຄັດລອກໄຟລ໌ kubectl-x ໄປຫາໄດເລກະທໍລີໃດໆໃນ PATH ຂອງທ່ານແລະເຮັດໃຫ້ມັນສາມາດປະຕິບັດໄດ້, ສໍາລັບການຍົກຕົວຢ່າງ chmod +x. ທັນທີຫຼັງຈາກນັ້ນທ່ານສາມາດໂທຫາ plugin ໄດ້ kubectl x.

ທ່ານສາມາດນໍາໃຊ້ຄໍາສັ່ງຕໍ່ໄປນີ້ເພື່ອລາຍຊື່ plugins ທັງຫມົດທີ່ຕິດຕັ້ງຢູ່ໃນລະບົບຂອງທ່ານ:

$ kubectl plugin list

ຄໍາສັ່ງນີ້ຍັງຈະສະແດງຄໍາເຕືອນຖ້າທ່ານມີ plugins ຫຼາຍອັນທີ່ມີຊື່ດຽວກັນ, ຫຼືຖ້າມີໄຟລ໌ plugins ທີ່ບໍ່ສາມາດປະຕິບັດໄດ້.

ຊອກຫາແລະຕິດຕັ້ງ plugins ໂດຍໃຊ້ Krew

ປລັກອິນ Kubectl ສາມາດຖືກແບ່ງປັນ ຫຼືໃຊ້ຄືນໄດ້ຄືກັບຊຸດຊອບແວ. ແຕ່ບ່ອນໃດທີ່ເຈົ້າສາມາດຊອກຫາ plugins ທີ່ຄົນອື່ນໄດ້ແບ່ງປັນ?

ໂຄງການ Kew ມີຈຸດປະສົງເພື່ອສະຫນອງການແກ້ໄຂທີ່ເປັນເອກະພາບສໍາລັບການແບ່ງປັນ, ຄົ້ນຫາ, ການຕິດຕັ້ງແລະການຄຸ້ມຄອງ plugins kubectl. ໂຄງການເອີ້ນຕົວເອງວ່າ "ຜູ້ຈັດການຊຸດສໍາລັບ kubectl plugins" (Krew ແມ່ນຄ້າຍຄືກັນກັບ Brew).

Krew ແມ່ນບັນຊີລາຍຊື່ຂອງ plugins kubectl ທີ່ທ່ານສາມາດເລືອກແລະຕິດຕັ້ງ. ໃນເວລາດຽວກັນ, Krew ຍັງເປັນ plugin ສໍາລັບ kubectl.

ນີ້ຫມາຍຄວາມວ່າການຕິດຕັ້ງ Krew ເຮັດວຽກທີ່ສໍາຄັນຄືກັບການຕິດຕັ້ງ plugin kubectl ອື່ນໆ. ທ່ານສາມາດຊອກຫາຄໍາແນະນໍາລາຍລະອຽດໄດ້ທີ່ ຫນ້າ GitHub.

ຄໍາສັ່ງ Krew ທີ່ສໍາຄັນທີ່ສຸດແມ່ນ:

# Поиск в списке плагинов
$ kubectl krew search [<query>]
# Посмотреть информацию о плагине
$ kubectl krew info <plugin>
# Установить плагин
$ kubectl krew install <plugin>
# Обновить все плагины до последней версии
$ kubectl krew upgrade
# Посмотреть все плагины, установленные через Krew
$ kubectl krew list
# Деинсталлировать плагин
$ kubectl krew remove <plugin>

ກະລຸນາສັງເກດວ່າການຕິດຕັ້ງ plugins ໂດຍໃຊ້ Krew ບໍ່ແຊກແຊງການຕິດຕັ້ງ plugins ໂດຍໃຊ້ວິທີການມາດຕະຖານທີ່ອະທິບາຍຂ້າງເທິງ.

ກະລຸນາສັງເກດວ່າຄໍາສັ່ງ kubectl krew list ສະແດງພຽງແຕ່ plugins ທີ່ຖືກຕິດຕັ້ງໂດຍໃຊ້ Krew, ໃນຂະນະທີ່ຄໍາສັ່ງ kubectl plugin list ລາຍຊື່ plugins ທັງຫມົດ, ນັ້ນແມ່ນ, ຜູ້ທີ່ຕິດຕັ້ງໂດຍໃຊ້ Krew ແລະການຕິດຕັ້ງໂດຍວິທີການອື່ນໆ.

ຊອກຫາ Plugins ຢູ່ບ່ອນອື່ນ

Krew ເປັນໂຄງການໄວຫນຸ່ມ, ປະຈຸບັນຢູ່ໃນຂອງຕົນ ບັນຊີລາຍການ ພຽງແຕ່ປະມານ 30 plugins. ຖ້າທ່ານບໍ່ສາມາດຊອກຫາສິ່ງທີ່ທ່ານຕ້ອງການ, ທ່ານສາມາດຊອກຫາ plugins ຢູ່ບ່ອນອື່ນ, ເຊັ່ນ GitHub.

ຂ້າພະເຈົ້າແນະນໍາໃຫ້ເບິ່ງຢູ່ໃນພາກ GitHub kubectl-plugins. ຢູ່ທີ່ນັ້ນເຈົ້າຈະພົບເຫັນຫລາຍສິບ plugins ທີ່ມີຢູ່ທີ່ມີມູນຄ່າການກວດສອບ.

ການຂຽນ plugins ຂອງທ່ານເອງ

ເຈົ້າສາມາດຕົວທ່ານເອງ ສ້າງ plugins - ມັນບໍ່ຍາກ. ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ສ້າງ​ການ​ປະ​ຕິ​ບັດ​ທີ່​ເຮັດ​ສິ່ງ​ທີ່​ທ່ານ​ຕ້ອງ​ການ​, ຊື່​ມັນ​ຄື​ kubectl-x ແລະຕິດຕັ້ງດັ່ງທີ່ອະທິບາຍຂ້າງເທິງ.

ໄຟລ໌ດັ່ງກ່າວອາດຈະເປັນ bash script, python script, ຫຼືຄໍາຮ້ອງສະຫມັກ GO ທີ່ຖືກລວບລວມ - ມັນບໍ່ສໍາຄັນ. ເງື່ອນໄຂດຽວແມ່ນວ່າມັນສາມາດຖືກປະຕິບັດໂດຍກົງໃນລະບົບປະຕິບັດການ.

ໃຫ້ສ້າງ plugin ຕົວຢ່າງໃນປັດຈຸບັນ. ໃນພາກກ່ອນ, ທ່ານໄດ້ໃຊ້ຄໍາສັ່ງ kubectl ເພື່ອບອກລາຍການບັນຈຸສໍາລັບແຕ່ລະຝັກ. ມັນງ່າຍທີ່ຈະປ່ຽນຄໍາສັ່ງນີ້ເຂົ້າໄປໃນ plugin ທີ່ທ່ານສາມາດໂທຫາໄດ້ເຊັ່ນ:. kubectl img.

ສ້າງໄຟລ໌ kubectl-img ເນື້ອໃນຕໍ່ໄປນີ້:

#!/bin/bash
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

ໃນປັດຈຸບັນເຮັດໃຫ້ໄຟລ໌ປະຕິບັດກັບ chmod +x kubectl-img ແລະຍ້າຍມັນໄປຫາໄດເລກະທໍລີໃດໆໃນ PATH ຂອງທ່ານ. ທັນທີຫຼັງຈາກນັ້ນທ່ານສາມາດນໍາໃຊ້ plugin ໄດ້ kubectl img.

ດັ່ງທີ່ໄດ້ກ່າວມາ, ປັ໊ກອິນ kubectl ສາມາດຂຽນເປັນພາສາການຂຽນໂປລແກລມຫຼືພາສາໃດໆ. ຖ້າທ່ານກໍາລັງໃຊ້ shell script, ປະໂຫຍດຂອງການສາມາດໂທຫາ kubectl ໄດ້ຢ່າງງ່າຍດາຍຈາກພາຍໃນ plugin. ຢ່າງໃດກໍຕາມ, ທ່ານສາມາດຂຽນ plugins ສະລັບສັບຊ້ອນຫຼາຍໃນພາສາການຂຽນໂປຼແກຼມທີ່ແທ້ຈິງໂດຍໃຊ້ ຫ້ອງສະໝຸດລູກຄ້າ Kubernetes. ຖ້າທ່ານກໍາລັງໃຊ້ Go, ທ່ານຍັງສາມາດໃຊ້ໄດ້ cli-runtime ຫໍສະຫມຸດ, ທີ່ມີໂດຍສະເພາະສໍາລັບການຂຽນ plugins kubectl.

ວິທີການແບ່ງປັນ plugins ຂອງທ່ານ

ຖ້າທ່ານຄິດວ່າປລັກອິນຂອງທ່ານສາມາດເປັນປະໂຫຍດຕໍ່ຜູ້ອື່ນ, ກະລຸນາແບ່ງປັນມັນຢູ່ໃນ GitHub. ໃຫ້ແນ່ໃຈວ່າເພີ່ມພວກມັນໃສ່ຫົວຂໍ້ kubectl-plugins.

ນອກນັ້ນທ່ານຍັງສາມາດຮ້ອງຂໍໃຫ້ plugin ຂອງທ່ານຖືກເພີ່ມໃສ່ ບັນຊີລາຍຊື່ Krew. ຄໍາແນະນໍາກ່ຽວກັບວິທີການເຮັດນີ້ແມ່ນຢູ່ໃນ ຄັງເກັບ GitHub.

ຄໍາສັ່ງສໍາເລັດ

ປັ໊ກອິນບໍ່ຮອງຮັບການຕື່ມຂໍ້ມູນອັດຕະໂນມັດ. ນັ້ນແມ່ນ, ທ່ານຕ້ອງໃສ່ຊື່ເຕັມຂອງ plugin ແລະຊື່ເຕັມຂອງການໂຕ້ຖຽງ.

GitHub kubectl repository ສໍາລັບຟັງຊັນນີ້ມີ ການຮ້ອງຂໍເປີດ. ສະນັ້ນມັນເປັນໄປໄດ້ວ່າຄຸນສົມບັດນີ້ຈະຖືກປະຕິບັດບາງຄັ້ງໃນອະນາຄົດ.

ໂຊກ​ດີ!!!

ມີຫຍັງອີກແດ່ທີ່ຈະອ່ານກ່ຽວກັບຫົວຂໍ້:

1. ສາມລະດັບການຂະຫຍາຍອັດຕະໂນມັດໃນ Kubernetes ແລະວິທີການນໍາໃຊ້ພວກມັນຢ່າງມີປະສິດທິພາບ.
2. Kubernetes ໃນຈິດໃຈຂອງການລະເມີດລິຂະສິດກັບແມ່ແບບການປະຕິບັດ.
3. ຊ່ອງຂອງພວກເຮົາປະມານ Kubernetes ໃນ Telegram.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com