Calico ສໍາລັບເຄືອຂ່າຍໃນ Kubernetes: ການແນະນໍາແລະປະສົບການເລັກນ້ອຍ

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

ການແນະນຳດ່ວນກ່ຽວກັບເຄື່ອງໃຊ້ເຄືອຂ່າຍ Kubernetes

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

ໃນສະພາບການຂອງບົດຄວາມນີ້, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະສັງເກດວ່າ K8s ຕົວຂອງມັນເອງບໍ່ມີຄວາມຮັບຜິດຊອບຕໍ່ການເຊື່ອມຕໍ່ເຄືອຂ່າຍລະຫວ່າງ container ແລະ nodes: ສໍາລັບນີ້, ຕ່າງໆ. ປລັກອິນ CNI (Container Networking Interface). ເພີ່ມເຕີມກ່ຽວກັບແນວຄວາມຄິດນີ້ພວກເຮົາ ພວກເຂົາເຈົ້າຍັງບອກຂ້າພະເຈົ້າ.

ຕົວຢ່າງ, ທົ່ວໄປທີ່ສຸດຂອງ plugins ເຫຼົ່ານີ້ແມ່ນ Flannel — ໃຫ້​ການ​ເຊື່ອມ​ຕໍ່​ເຄືອ​ຂ່າຍ​ຢ່າງ​ເຕັມ​ທີ່​ລະ​ຫວ່າງ nodes ກຸ່ມ​ທັງ​ຫມົດ​ໂດຍ​ການ​ເພີ່ມ​ຂົວ​ໃນ​ແຕ່​ລະ node​, ການ​ມອບ​ຫມາຍ subnet ກັບ​ມັນ​. ຢ່າງໃດກໍ່ຕາມ, ການເຂົ້າເຖິງທີ່ສົມບູນ ແລະບໍ່ມີລະບຽບແມ່ນບໍ່ມີປະໂຫຍດສະເໝີໄປ. ເພື່ອຮັບປະກັນຄວາມໂດດດ່ຽວເລັກນ້ອຍໃນກຸ່ມ, ມັນຈໍາເປັນຕ້ອງແຊກແຊງໃນການຕັ້ງຄ່າຂອງ firewall. ໃນກໍລະນີທົ່ວໄປ, ມັນຖືກຈັດໃສ່ພາຍໃຕ້ການຄວບຄຸມຂອງ CNI ດຽວກັນ, ນັ້ນແມ່ນເຫດຜົນທີ່ວ່າການແຊກແຊງຂອງພາກສ່ວນທີສາມໃນ iptables ສາມາດຖືກຕີຄວາມບໍ່ຖືກຕ້ອງຫຼືຖືກລະເລີຍທັງຫມົດ.

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

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

ມັນເປັນເຫດຜົນວ່າມີ 2 ປະເພດຂອງການຈະລາຈອນ: ເຂົ້າໄປໃນຝັກ (Ingress) ແລະຂາອອກ (Egress).

ຕົວ​ຈິງ​ແລ້ວ, ການ​ເມືອງ​ແບ່ງ​ອອກ​ເປັນ 2 ປະ​ເພດ​ນີ້​ອີງ​ຕາມ​ທິດ​ທາງ​ການ​ເຄື່ອນ​ໄຫວ.

ຄຸນລັກສະນະທີ່ຕ້ອງການຕໍ່ໄປແມ່ນຕົວເລືອກ; ຜູ້ທີ່ກົດລະບຽບໃຊ້. ນີ້ອາດຈະເປັນຝັກ (ຫຼືກຸ່ມຂອງຝັກ) ຫຼືສະພາບແວດລ້ອມ (ເຊັ່ນ: ຊ່ອງຊື່). ລາຍລະອຽດທີ່ສໍາຄັນ: ທັງສອງປະເພດຂອງວັດຖຸເຫຼົ່ານີ້ຕ້ອງມີປ້າຍ (ປ້າຍ ໃນຄໍາທີ່ໃຊ້ໃນ Kubernetes) - ເຫຼົ່ານີ້ແມ່ນສິ່ງທີ່ນັກການເມືອງດໍາເນີນການກັບ.

ນອກເໜືອໄປຈາກຕົວເລືອກຈຳນວນຈຳກັດ, ຮວມກັນດ້ວຍປ້າຍກຳກັບບາງປະເພດ, ມັນເປັນໄປໄດ້ທີ່ຈະຂຽນກົດລະບຽບເຊັ່ນ “ອະນຸຍາດ/ປະຕິເສດທຸກຢ່າງ/ທຸກຄົນ” ໃນຮູບແບບຕ່າງໆ. ສໍາລັບຈຸດປະສົງນີ້, ການກໍ່ສ້າງຂອງແບບຟອມແມ່ນໃຊ້:

  podSelector: {}
  ingress: []
  policyTypes:
  - Ingress

— ໃນ​ຕົວ​ຢ່າງ​ນີ້, ຝັກ​ທັງ​ຫມົດ​ໃນ​ສະ​ພາບ​ແວດ​ລ້ອມ​ແມ່ນ​ໄດ້​ຖືກ​ຕັນ​ຈາກ​ການ​ຈະ​ລາ​ຈອນ​ເຂົ້າ. ພຶດຕິກໍາກົງກັນຂ້າມສາມາດບັນລຸໄດ້ດ້ວຍການກໍ່ສ້າງດັ່ງຕໍ່ໄປນີ້:

  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

ເຊັ່ນດຽວກັນສໍາລັບການຂາອອກ:

  podSelector: {}
  policyTypes:
  - Egress

- ເພື່ອປິດມັນ. ແລະນີ້ແມ່ນສິ່ງທີ່ຈະປະກອບມີ:

  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

ກັບຄືນໄປຫາທາງເລືອກຂອງ plugin CNI ສໍາລັບກຸ່ມ, ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າ ບໍ່ແມ່ນທຸກໆ plugin ເຄືອຂ່າຍສະຫນັບສະຫນູນ NetworkPolicy. ຕົວຢ່າງ, Flannel ທີ່ໄດ້ກ່າວມາແລ້ວບໍ່ຮູ້ວິທີການກໍານົດນະໂຍບາຍເຄືອຂ່າຍ, ເຊິ່ງ ມັນເວົ້າໂດຍກົງ ໃນ repository ຢ່າງເປັນທາງການ. ທາງເລືອກອື່ນຍັງຖືກກ່າວເຖິງຢູ່ທີ່ນັ້ນ - ໂຄງການ Open Source Calico, ເຊິ່ງຂະຫຍາຍຊຸດມາດຕະຖານຂອງ Kubernetes APIs ຢ່າງຫຼວງຫຼາຍໃນແງ່ຂອງນະໂຍບາຍເຄືອຂ່າຍ.

ຮູ້ຈັກ Calico: ທິດສະດີ

plugin Calico ສາມາດຖືກນໍາໃຊ້ໃນການປະສົມປະສານກັບ Flannel (ໂຄງການຍ່ອຍ Canal) ຫຼືເປັນເອກະລາດ, ກວມເອົາທັງການເຊື່ອມຕໍ່ເຄືອຂ່າຍ ແລະຄວາມສາມາດໃນການຈັດການຄວາມພ້ອມ.

ໂອກາດອັນໃດທີ່ການໃຊ້ວິທີແກ້ໄຂ K8s “boxed” ແລະ API ທີ່ກໍານົດໄວ້ຈາກ Calico ໃຫ້?

ນີ້ແມ່ນສິ່ງທີ່ສ້າງຂຶ້ນໃນ NetworkPolicy:

• ນັກການເມືອງຖືກຈໍາກັດໂດຍສະພາບແວດລ້ອມ;
• ນະໂຍບາຍຖືກນຳໃຊ້ກັບຝັກທີ່ມີປ້າຍກຳກັບ;
• ກົດລະບຽບສາມາດນໍາໃຊ້ກັບ pods, ສະພາບແວດລ້ອມຫຼື subnets;
• ກົດລະບຽບສາມາດປະກອບມີໂປໂຕຄອນ, ຊື່ຫຼືສັນຍາລັກຂອງພອດສະເພາະ.

ນີ້ແມ່ນວິທີການ Calico ຂະຫຍາຍຫນ້າທີ່ເຫຼົ່ານີ້:

• ນະ​ໂຍ​ບາຍ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ນໍາ​ໃຊ້​ກັບ​ວັດ​ຖຸ​ໃດ​ຫນຶ່ງ​: pod, container​, virtual machine ຫຼື​ການ​ໂຕ້​ຕອບ​;
• ກົດລະບຽບສາມາດປະກອບມີການປະຕິບັດສະເພາະ (ການຫ້າມ, ການອະນຸຍາດ, ການຕັດໄມ້);
• ເປົ້າຫມາຍຫຼືແຫຼ່ງຂອງກົດລະບຽບສາມາດເປັນພອດ, ຊ່ວງຂອງພອດ, ໂປໂຕຄອນ, HTTP ຫຼື ICMP attributes, IP ຫຼື subnet (ຮຸ່ນທີ 4 ຫຼື 6), ຕົວເລືອກໃດໆ (nodes, hosts, ສະພາບແວດລ້ອມ);
• ນອກຈາກນັ້ນ, ທ່ານສາມາດຄວບຄຸມເສັ້ນທາງຂອງການຈະລາຈອນໂດຍໃຊ້ການຕັ້ງຄ່າ DNAT ແລະນະໂຍບາຍການສົ່ງຕໍ່ການຈະລາຈອນ.

ທໍາອິດ commits ສຸດ GitHub ໃນ calico repository ວັນທີກັບຄືນໄປບ່ອນເດືອນກໍລະກົດ 2016, ແລະຫນຶ່ງປີຕໍ່ມາໂຄງການໄດ້ຮັບຕໍາແຫນ່ງນໍາຫນ້າໃນການຈັດຕັ້ງການເຊື່ອມຕໍ່ເຄືອຂ່າຍ Kubernetes - ນີ້ແມ່ນຫຼັກຖານ, ຕົວຢ່າງ, ໂດຍຜົນການສໍາຫຼວດ, ດໍາເນີນໂດຍ The New Stack:

ຫຼາຍການແກ້ໄຂການຄຸ້ມຄອງຂະຫນາດໃຫຍ່ທີ່ມີ K8s, ເຊັ່ນ: Amazon EKS, Azure AKS, Google GKE ແລະຄົນອື່ນໄດ້ເລີ່ມແນະນໍາມັນສໍາລັບການນໍາໃຊ້.

ສໍາລັບການປະຕິບັດ, ທຸກສິ່ງທຸກຢ່າງແມ່ນຍິ່ງໃຫຍ່ຢູ່ທີ່ນີ້. ໃນການທົດສອບຜະລິດຕະພັນຂອງພວກເຂົາ, ທີມງານພັດທະນາ Calico ໄດ້ສະແດງໃຫ້ເຫັນການປະຕິບັດທາງດາລາສາດ, ແລ່ນຫຼາຍກວ່າ 50000 containers ໃນ 500 nodes ທາງດ້ານຮ່າງກາຍທີ່ມີອັດຕາການສ້າງ 20 containers ຕໍ່ວິນາທີ. ບໍ່ພົບບັນຫາໃດໆກັບການປັບຂະໜາດ. ຜົນໄດ້ຮັບດັ່ງກ່າວ ໄດ້ຖືກປະກາດ ແລ້ວຢູ່ໃນການປະກາດສະບັບທໍາອິດ. ການສຶກສາເອກະລາດທີ່ສຸມໃສ່ການສົ່ງຜ່ານແລະການບໍລິໂພກຊັບພະຍາກອນຍັງຢືນຢັນວ່າການປະຕິບັດຂອງ Calico ແມ່ນດີເທົ່າກັບ Flannel. ຕົວຢ່າງເຊັ່ນ:

ໂຄງ​ການ​ດັ່ງ​ກ່າວ​ແມ່ນ​ການ​ພັດ​ທະ​ນາ​ຢ່າງ​ວ່ອງ​ໄວ​, ມັນ​ສະ​ຫນັບ​ສະ​ຫນູນ​ການ​ເຮັດ​ວຽກ​ໃນ​ການ​ແກ້​ໄຂ​ທີ່​ນິ​ຍົມ K8s​, OpenShift​, OpenStack​, ມັນ​ເປັນ​ໄປ​ໄດ້​ທີ່​ຈະ​ນໍາ​ໃຊ້ Calico ໃນ​ເວ​ລາ​ທີ່​ການ​ນໍາ​ໃຊ້​ກຸ່ມ​ການ​ນໍາ​ໃຊ້​. ໂຄບ, ມີການອ້າງອີງເຖິງການກໍ່ສ້າງເຄືອຂ່າຍ Service Mesh (ນີ້ແມ່ນຕົວຢ່າງ ໃຊ້ຮ່ວມກັບ Istio).

ປະຕິບັດກັບ Calico

ໃນກໍລະນີທົ່ວໄປຂອງການນໍາໃຊ້ vanilla Kubernetes, ການຕິດຕັ້ງ CNI ມາລົງກັບການນໍາໃຊ້ໄຟລ໌ calico.yaml, ດາວໂຫຼດຈາກເວັບໄຊທ໌ທາງການ, ໂດຍ​ການ​ນໍາ​ໃຊ້​ kubectl apply -f.

ຕາມກົດລະບຽບ, ປັ໊ກອິນສະບັບປະຈຸບັນແມ່ນເຂົ້າກັນໄດ້ກັບ Kubernetes 2-3 ຮຸ່ນຫຼ້າສຸດ: ການດໍາເນີນງານໃນຮຸ່ນເກົ່າແມ່ນບໍ່ມີການທົດສອບແລະບໍ່ໄດ້ຮັບການຮັບປະກັນ. ອີງຕາມນັກພັດທະນາ, Calico ແລ່ນຢູ່ໃນ Linux kernels ຂ້າງເທິງ 3.10 ແລ່ນ CentOS 7, Ubuntu 16 ຫຼື Debian 8, ຢູ່ເທິງສຸດຂອງ iptables ຫຼື IPVS.

ຄວາມໂດດດ່ຽວພາຍໃນສະພາບແວດລ້ອມ

ສໍາລັບຄວາມເຂົ້າໃຈທົ່ວໄປ, ໃຫ້ພວກເຮົາເບິ່ງກໍລະນີທີ່ງ່າຍດາຍເພື່ອເຂົ້າໃຈວ່ານະໂຍບາຍເຄືອຂ່າຍໃນຫມາຍເຫດ Calico ແຕກຕ່າງຈາກມາດຕະຖານແນວໃດແລະວິທີການສ້າງກົດລະບຽບເຮັດໃຫ້ຄວາມງ່າຍດາຍຂອງການອ່ານແລະຄວາມຍືດຫຍຸ່ນຂອງການຕັ້ງຄ່າຂອງພວກເຂົາ:

ມີ 2 ແອັບພລິເຄຊັນເວັບທີ່ຖືກນຳໃຊ້ຢູ່ໃນກຸ່ມ: ໃນ Node.js ແລະ PHP, ນຶ່ງໃນນັ້ນໃຊ້ Redis. ເພື່ອບລັອກການເຂົ້າເຖິງ Redis ຈາກ PHP, ໃນຂະນະທີ່ຮັກສາການເຊື່ອມຕໍ່ກັບ Node.js, ພຽງແຕ່ໃຊ້ນະໂຍບາຍຕໍ່ໄປນີ້:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-redis-nodejs
spec:
  podSelector:
    matchLabels:
      service: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: nodejs
    ports:
    - protocol: TCP
      port: 6379

ໂດຍພື້ນຖານແລ້ວພວກເຮົາອະນຸຍາດໃຫ້ການຈະລາຈອນຂາເຂົ້າໄປຫາພອດ Redis ຈາກ Node.js. ແລະພວກເຂົາຢ່າງຊັດເຈນບໍ່ໄດ້ຫ້າມຫຍັງອີກ. ທັນທີທີ່ NetworkPolicy ປະກົດຂຶ້ນ, ຕົວເລືອກທັງໝົດທີ່ໄດ້ກ່າວມາໃນມັນເລີ່ມໂດດດ່ຽວ, ເວັ້ນເສຍແຕ່ໄດ້ລະບຸໄວ້ເປັນຢ່າງອື່ນ. ຢ່າງໃດກໍຕາມ, ກົດລະບຽບການໂດດດ່ຽວບໍ່ໄດ້ນໍາໃຊ້ກັບວັດຖຸອື່ນໆທີ່ບໍ່ໄດ້ກວມເອົາໂດຍຕົວເລືອກ.

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

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-nodejs
spec:
  selector: service == 'redis'
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: service == 'nodejs'
    destination:
      ports:
      - 6379

ໂຄງສ້າງທີ່ໄດ້ກ່າວມາຂ້າງເທິງສໍາລັບການອະນຸຍາດໃຫ້ຫຼືປະຕິເສດການຈະລາຈອນທັງຫມົດໂດຍຜ່ານ NetworkPolicy API ປົກກະຕິປະກອບດ້ວຍໂຄງສ້າງທີ່ມີວົງເລັບທີ່ຍາກທີ່ຈະເຂົ້າໃຈແລະຈື່ຈໍາ. ໃນກໍລະນີຂອງ Calico, ເພື່ອປ່ຽນເຫດຜົນຂອງກົດລະບຽບຂອງ Firewall ກັບກົງກັນຂ້າມ, ພຽງແຕ່ປ່ຽນ action: Allow ສຸດ action: Deny.

ການໂດດດ່ຽວໂດຍສະພາບແວດລ້ອມ

ຕອນນີ້ຈິນຕະນາການສະຖານະການທີ່ແອັບພລິເຄຊັນສ້າງຕົວຊີ້ບອກທາງທຸລະກິດສໍາລັບການລວບລວມໃນ Prometheus ແລະການວິເຄາະຕື່ມອີກໂດຍໃຊ້ Grafana. ການອັບໂຫລດອາດມີຂໍ້ມູນທີ່ລະອຽດອ່ອນ, ເຊິ່ງອີກເທື່ອຫນຶ່ງສາມາດເບິ່ງໄດ້ໂດຍສາທາລະນະໂດຍຄ່າເລີ່ມຕົ້ນ. ຂໍ​ໃຫ້​ເຊື່ອງ​ຂໍ້​ມູນ​ນີ້​ຈາກ​ຕາ prying​:

ຕາມກົດລະບຽບ, Prometheus ແມ່ນຖືກຈັດໃສ່ໃນສະພາບແວດລ້ອມການບໍລິການແຍກຕ່າງຫາກ - ໃນຕົວຢ່າງມັນຈະເປັນ namespace ແບບນີ້:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    module: prometheus
  name: kube-prometheus

ພາກສະຫນາມ metadata.labels ນີ້​ໄດ້​ກາຍ​ເປັນ​ອຸ​ປະ​ຕິ​ເຫດ​ບໍ່​ມີ​. ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, namespaceSelector (ເຊັ່ນດຽວກັນກັບ podSelector) ດໍາເນີນການກັບປ້າຍຊື່. ດັ່ງນັ້ນ, ເພື່ອອະນຸຍາດໃຫ້ວັດແທກຈາກຝັກທັງຫມົດໃນພອດສະເພາະ, ທ່ານຈະຕ້ອງເພີ່ມປະເພດຂອງປ້າຍ (ຫຼືເອົາຈາກທີ່ມີຢູ່ແລ້ວ), ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ການຕັ້ງຄ່າເຊັ່ນ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          module: prometheus
    ports:
    - protocol: TCP
      port: 9100

ແລະຖ້າທ່ານໃຊ້ນະໂຍບາຍ Calico, syntax ຈະເປັນແບບນີ້:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  ingress:
  - action: Allow
    protocol: TCP
    source:
      namespaceSelector: module == 'prometheus'
    destination:
      ports:
      - 9100

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

ການປະຕິບັດທີ່ດີທີ່ສຸດ, ອີງຕາມຜູ້ສ້າງຂອງ Calico, ແມ່ນວິທີການ "ປິດກັ້ນທຸກສິ່ງທຸກຢ່າງແລະເປີດຢ່າງຈະແຈ້ງສິ່ງທີ່ທ່ານຕ້ອງການ", ບັນທຶກໄວ້ໃນເອກະສານ. ເອກະສານທາງການ (ຄົນອື່ນປະຕິບັດຕາມວິທີການທີ່ຄ້າຍຄືກັນ - ໂດຍສະເພາະ, ໃນ ບົດຄວາມທີ່ໄດ້ກ່າວມາແລ້ວ).

ການນໍາໃຊ້ວັດຖຸ Calico ເພີ່ມເຕີມ

ຂ້ອຍຂໍເຕືອນເຈົ້າວ່າຜ່ານຊຸດ Calico APIs ຂະຫຍາຍເຈົ້າສາມາດຄວບຄຸມການມີຂອງ nodes, ບໍ່ຈໍາກັດ pods. ໃນຕົວຢ່າງຕໍ່ໄປນີ້ໂດຍໃຊ້ GlobalNetworkPolicy ຄວາມສາມາດໃນການຜ່ານການຮ້ອງຂໍ ICMP ໃນ cluster ແມ່ນປິດ (ຕົວຢ່າງ, pings ຈາກ pod ກັບ node, ລະຫວ່າງ pods, ຫຼືຈາກ node ກັບ pod IP):

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: block-icmp
spec:
  order: 200
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
    protocol: ICMP
  egress:
  - action: Deny
    protocol: ICMP

ໃນກໍລະນີຂ້າງເທິງ, ມັນຍັງເປັນໄປໄດ້ສໍາລັບ nodes ກຸ່ມທີ່ຈະ "ເອື້ອມອອກ" ໄປຫາກັນແລະກັນໂດຍຜ່ານ ICMP. ແລະບັນຫານີ້ຖືກແກ້ໄຂໂດຍວິທີການ GlobalNetworkPolicy, ນຳໃຊ້ກັບນິຕິບຸກຄົນ HostEndpoint:

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: deny-icmp-kube-02
spec:
  selector: "role == 'k8s-node'"
  order: 0
  ingress:
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow
    protocol: ICMP
---
apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: kube-02-eth0
  labels:
    role: k8s-node
spec:
  interfaceName: eth0
  node: kube-02
  expectedIPs: ["192.168.2.2"]

ກໍລະນີ VPN

ສຸດທ້າຍ, ຂ້ອຍຈະໃຫ້ຕົວຢ່າງທີ່ແທ້ຈິງຂອງການໃຊ້ຟັງຊັນ Calico ສໍາລັບກໍລະນີຂອງການໂຕ້ຕອບຂອງກຸ່ມຢູ່ໃກ້ໆ, ເມື່ອມາດຕະຖານທີ່ກໍານົດໄວ້ຂອງນະໂຍບາຍບໍ່ພຽງພໍ. ເພື່ອເຂົ້າເຖິງແອັບພລິເຄຊັນເວັບ, ລູກຄ້າໃຊ້ອຸໂມງ VPN, ແລະການເຂົ້າເຖິງນີ້ຖືກຄວບຄຸມຢ່າງເຂັ້ມງວດ ແລະຈຳກັດຢູ່ໃນລາຍຊື່ສະເພາະຂອງບໍລິການທີ່ອະນຸຍາດໃຫ້ໃຊ້:

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

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

ຜົນຂອງການຄົ້ນຫາຜ່ານການແກ້ໄຂທີ່ເປັນໄປໄດ້, ຕໍ່ໄປນີ້ໄດ້ຖືກເລືອກ:

1. Pods ທີ່ມີ VPN ແມ່ນກໍານົດເວລາຕໍ່ node ໃນ hostNetwork, ນັ້ນແມ່ນ, ກັບ IP ຕົວຈິງ.
2. ການ​ບໍ​ລິ​ການ​ແມ່ນ​ໄດ້​ຮັບ​ການ​ອອກ​ນອກ​ໂດຍ​ຜ່ານ​ການ​ ClusterIP. ພອດໄດ້ຖືກຕິດຕັ້ງຢູ່ໃນໂຫນດ, ເຊິ່ງສາມາດເຂົ້າເຖິງໄດ້ຈາກພາຍນອກດ້ວຍການຈອງເລັກນ້ອຍ (ມີເງື່ອນໄຂຂອງທີ່ຢູ່ IP ທີ່ແທ້ຈິງ).
3. ການກໍານົດ node ທີ່ pod rose ແມ່ນເກີນຂອບເຂດຂອງເລື່ອງຂອງພວກເຮົາ. ຂ້າພະເຈົ້າພຽງແຕ່ເວົ້າວ່າທ່ານສາມາດ "ເລັບ" ການບໍລິການຢ່າງແຫນ້ນຫນາກັບ node ຫຼືຂຽນບໍລິການ sidecar ຂະຫນາດນ້ອຍທີ່ຈະຕິດຕາມກວດກາທີ່ຢູ່ IP ໃນປະຈຸບັນຂອງການບໍລິການ VPN ແລະແກ້ໄຂບັນທຶກ DNS ທີ່ລົງທະບຽນກັບລູກຄ້າ - ໃຜກໍ່ຕາມທີ່ມີຈິນຕະນາການພຽງພໍ.

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

apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: vpnclient-eth0
  labels:
    role: vpnclient
    environment: production
spec:
  interfaceName: "*"
  node: kube-02
  expectedIPs: ["172.176.176.2"]
---
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: vpn-rules
spec:
  selector: "role == 'vpnclient'"
  order: 0
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    protocol: TCP
    destination:
      ports: [6379]
  - action: Allow
    protocol: UDP
    destination:
      ports: [53, 67]

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

ຜົນໄດ້ຮັບ

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

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

PS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ການແນະນໍາກ່ຽວກັບນະໂຍບາຍເຄືອຂ່າຍ Kubernetes ສໍາລັບຜູ້ຊ່ຽວຊານດ້ານຄວາມປອດໄພ"
• "ຄູ່ມືຮູບພາບກ່ຽວກັບເຄືອຂ່າຍໃນ Kubernetes": ພາກທີ 1 ແລະ 2 (ຕົວແບບເຄືອຂ່າຍ, ເຄືອຂ່າຍຊ້ອນກັນ), ພາກ​ທີ 3 (ການ​ບໍ​ລິ​ການ​ແລະ​ການ​ປຸງ​ແຕ່ງ​ຈະ​ລາ​ຈອນ​);
• «Container Networking Interface (CNI) - ການໂຕ້ຕອບເຄືອຂ່າຍ ແລະມາດຕະຖານສໍາລັບກ່ອງບັນຈຸ Linux".

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