Өгүүллийн зорилго нь уншигчдад Кубернетес дэх сүлжээний бодлого, удирдлагын үндсэн зарчмуудыг танилцуулах, түүнчлэн стандарт чадавхийг өргөжүүлдэг гуравдагч этгээдийн Calico залгаастай танилцуулах явдал юм. Замын дагуу тохиргооны хялбар байдал болон зарим функцуудыг бидний үйл ажиллагааны туршлагаас бодит жишээнүүдийг ашиглан харуулах болно.
Kubernetes сүлжээний хэрэгслийн тухай товч танилцуулга
Kubernetes кластерыг сүлжээгүйгээр төсөөлөхийн аргагүй. Бид тэдгээрийн үндсэн талаархи материалыг аль хэдийн нийтэлсэн: ""Мөн"".
Энэ нийтлэлийн хүрээнд K8 нь өөрөө контейнер ба зангилааны хоорондох сүлжээний холболтыг хариуцахгүй гэдгийг анхаарах нь чухал юм: үүний тулд янз бүрийн CNI залгаасууд (Container Networking Interface). Энэ үзэл баримтлалын талаар бид илүү дэлгэрэнгүй .
Жишээлбэл, эдгээр залгаасуудын хамгийн түгээмэл нь — зангилаа бүр дээр гүүр босгож, түүнд дэд сүлжээ хуваарилах замаар бүх кластерийн зангилааны хооронд сүлжээний бүрэн холболтыг хангадаг. Гэсэн хэдий ч бүрэн, зохицуулалтгүй хүртээмжтэй байх нь үргэлж ашигтай байдаггүй. Кластер дахь хамгийн бага тусгаарлалтыг хангахын тулд галт хананы тохиргоонд хөндлөнгөөс оролцох шаардлагатай. Ерөнхийдөө энэ нь ижил CNI-ийн хяналтанд байдаг тул iptables-д гуравдагч этгээдийн хөндлөнгийн оролцоог буруу тайлбарлаж эсвэл бүрмөсөн үл тоомсорлож болно.
Мөн Kubernetes кластерт сүлжээний бодлогын удирдлагыг зохион байгуулах "хайрцагнаас гадуур" хангагдсан болно . Сонгосон нэрийн орон зайд тараагдсан энэ нөөц нь нэг програмаас нөгөөд хандах хандалтыг ялгах дүрмийг агуулж болно. Энэ нь мөн танд тодорхой под, орчин (нэрийн орон зай) эсвэл 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 төрөл байдаг нь логик юм: pod руу орох (Ingress) ба түүнээс гарах (Egress).
Уг нь улс төрийг хөдөлгөөний чиг хандлагаар нь энэ 2 ангилалд хуваадаг.
Дараагийн шаардлагатай шинж чанар бол сонгогч юм; дүрэм үйлчилдэг хүн. Энэ нь pod (эсвэл бүлэг pods) эсвэл орчин (жишээ нь нэрийн орон зай) байж болно. Чухал мэдээлэл: эдгээр объектын хоёр төрөл нь шошго агуулсан байх ёстой (хаяг Kubernetes нэр томъёонд) - эдгээр нь улс төрчдийн хамтран ажилладаг хүмүүс юм.
Зарим төрлийн шошгон дээр нэгтгэсэн хязгаарлагдмал тооны сонгогчоос гадна "Бүхнийг/бүгдийг зөвшөөрөх/татгалзах" гэх мэт дүрмийг өөр өөр хувилбараар бичих боломжтой. Энэ зорилгоор дараах хэлбэрийн бүтцийг ашиглана.
podSelector: {}
ingress: []
policyTypes:
- Ingress— энэ жишээнд хүрээлэн буй орчны бүх хонхорцог орж ирж буй урсгалаас хаагдсан байна. Эсрэг зан үйлийг дараахь бүтээн байгуулалтаар хийж болно.
podSelector: {}
ingress:
- {}
policyTypes:
- IngressҮүнтэй адилаар гарахын хувьд:
podSelector: {}
policyTypes:
- Egress- унтраахын тулд. Мөн энд юу оруулах вэ:
podSelector: {}
egress:
- {}
policyTypes:
- EgressКластерт зориулсан CNI залгаасын сонголт руу буцахдаа үүнийг тэмдэглэх нь зүйтэй Сүлжээний залгаас бүр NetworkPolicy-г дэмждэггүй. Жишээлбэл, аль хэдийн дурдсан Flannel сүлжээний бодлогыг хэрхэн тохируулахаа мэдэхгүй байна албан ёсны санд. Нээлттэй эхийн төсөл гэсэн өөр хувилбарыг бас дурьдсан болно , энэ нь сүлжээний бодлогын хувьд Kubernetes API-ийн стандарт багцыг ихээхэн өргөжүүлдэг.
Каликотой танилцах: онол
Calico залгаасыг Flannel-тэй нэгтгэхэд ашиглаж болно (дэд төсөл ) эсвэл бие даан, сүлжээний холболт болон хүртээмжийн удирдлагын чадавхийг хоёуланг нь хамарна.
K8s "хайрцагласан" шийдэл болон Calico-ийн API багцыг ашиглах нь ямар боломжийг олгодог вэ?
NetworkPolicy-д суулгасан зүйлс энд байна:
- улс төрчид хүрээлэн буй орчиндоо хязгаарлагддаг;
- шошгон дээр тэмдэглэсэн хонхорцогт бодлогыг хэрэгжүүлдэг;
- дүрмүүдийг под, орчин эсвэл дэд сүлжээнд хэрэглэж болно;
- дүрмүүд нь протокол, нэрлэсэн эсвэл симбол портын үзүүлэлтүүдийг агуулж болно.
Calico эдгээр функцийг хэрхэн өргөтгөж байгааг эндээс үзнэ үү:
- бодлогуудыг ямар ч объектод хэрэглэж болно: pod, контейнер, виртуал машин эсвэл интерфейс;
- дүрэм нь тодорхой үйлдлийг агуулж болно (хориглох, зөвшөөрөл, мод бэлтгэх);
- дүрмийн зорилт буюу эх сурвалж нь порт, олон тооны портууд, протоколууд, HTTP эсвэл ICMP шинж чанарууд, IP эсвэл дэд сүлжээ (4 эсвэл 6-р үе), дурын сонгогч (зангилаа, хост, орчин) байж болно;
- Нэмж дурдахад, та DNAT тохиргоо болон урсгалыг дамжуулах бодлогыг ашиглан замын хөдөлгөөний урсгалыг зохицуулах боломжтой.
Calico репозитор дахь GitHub дээрх анхны амлалтууд 2016 оны XNUMX-р сараас эхэлсэн бөгөөд жилийн дараа уг төсөл Kubernetes сүлжээний холболтыг зохион байгуулахад тэргүүлэгч байр суурийг эзэлсэн нь жишээлбэл, судалгааны үр дүнгээс харагдаж байна. :
гэх мэт K8-тай олон том менежменттэй шийдлүүд , , болон бусад хүмүүс үүнийг ашиглахыг санал болгож эхлэв.
Гүйцэтгэлийн хувьд энд бүх зүйл сайхан байна. Бүтээгдэхүүнээ туршихдаа Calico хөгжүүлэлтийн баг секундэд 50000 контейнер үүсгэх хурдтайгаар 500 физик зангилаа дээр 20 гаруй контейнер ажиллуулж, одон орон судлалын гүйцэтгэлийг харуулсан. Томруулахад ямар ч асуудал илрээгүй. Ийм үр дүн аль хэдийн анхны хувилбарыг зарлах үед. Дамжуулах чадвар, нөөцийн хэрэглээнд анхаарлаа хандуулсан бие даасан судалгаанууд нь мөн Calico-ийн гүйцэтгэл нь Flannel-ийнхтэй бараг адил гэдгийг баталж байна. :
Төсөл маш хурдацтай хөгжиж байгаа бөгөөд энэ нь K8s, OpenShift, OpenStack-ийн удирддаг алдартай шийдлүүдийн ажлыг дэмждэг бөгөөд кластерийг ашиглахдаа Calico-г ашиглах боломжтой. , Service Mesh сүлжээг байгуулах тухай лавлагаа байдаг ( Istio-тай хамт хэрэглэгддэг).
Каликотой дасгал хий
Vanilla Kubernetes ашиглах ерөнхий тохиолдолд CNI суулгах нь файлыг ашиглахад хүргэдэг calico.yaml, , ашиглах замаар kubectl apply -f.
Дүрмээр бол залгаасын одоогийн хувилбар нь Kubernetes-ийн хамгийн сүүлийн үеийн 2-3 хувилбартай нийцдэг: хуучин хувилбаруудын ажиллагааг шалгаагүй бөгөөд баталгаагүй болно. Хөгжүүлэгчдийн үзэж байгаагаар Calico нь iptables эсвэл IPVS дээр CentOS 3.10, Ubuntu 7 эсвэл Debian 16 үйлдлийн системтэй 8-аас дээш хувилбар бүхий Linux цөмүүд дээр ажилладаг.
Хүрээлэн буй орчны тусгаарлалт
Ерөнхий ойлголттой болохын тулд Calico тэмдэглэгээн дэх сүлжээний бодлого нь стандартаас хэрхэн ялгаатай, дүрэм бий болгох арга нь тэдгээрийн уншигдах болон тохиргооны уян хатан байдлыг хэрхэн хялбаршуулдаг болохыг ойлгох энгийн жишээг харцгаая.
Кластерт байрлуулсан 2 вэб програм байдаг: Node.js болон PHP дээр, тэдгээрийн нэг нь Redis ашигладаг. Node.js-тэй холболтыг хадгалахын зэрэгцээ PHP-ээс Redis-д хандах хандалтыг хаахын тулд дараах бодлогыг хэрэгжүүлнэ үү.
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Үндсэндээ бид Node.js-ээс Redis порт руу орж ирж буй урсгалыг зөвшөөрсөн. Тэд өөр юу ч хориглоогүй нь тодорхой. NetworkPolicy гарч ирмэгц, өөрөөр заагаагүй бол түүнд дурдсан бүх сонгогчид тусгаарлагдаж эхэлнэ. Гэсэн хэдий ч, тусгаарлах дүрэм нь сонгогчид хамрагдаагүй бусад объектод хамаарахгүй.
Жишээ нь ашигладаг apiVersion Kubernetes хайрцагнаас гарсан боловч үүнийг ашиглахад юу ч саад болохгүй . Тэнд байгаа синтакс нь илүү нарийвчилсан тул дээрх тохиолдлын дүрмийг дараах хэлбэрээр дахин бичих шаардлагатай болно.
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-ийн хувьд галт ханын дүрмийн логикийг эсрэгээр нь өөрчлөхийн тулд зүгээр л өөрчлөх хэрэгтэй action: Allow тухай action: Deny.
Орчноос нь тусгаарлах
Одоо програм нь Prometheus-д цуглуулж, Grafana ашиглан цаашдын дүн шинжилгээ хийх зорилгоор бизнесийн хэмжүүр үүсгэдэг нөхцөл байдлыг төсөөлөөд үз дээ. Байршуулалт нь анхдагчаар дахин олон нийтэд харагдах боломжтой нууц мэдээлэл агуулж болзошгүй. Энэ өгөгдлийг сониуч нүднээс нууцгаая.
Прометейг дүрмээр бол тусдаа үйлчилгээний орчинд байрлуулдаг - жишээн дээр энэ нь иймэрхүү нэрийн орон зай байх болно:
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 бодлогуудыг ашиглавал синтакс нь дараах байдалтай байна:
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 API-ийн өргөтгөсөн багцаар дамжуулан та зөвхөн хонгилоор хязгаарлагдахгүй зангилааны хүртээмжийг зохицуулах боломжтой гэдгийг сануулъя. Дараах жишээнд ашиглаж байна GlobalNetworkPolicy кластер дахь ICMP хүсэлтийг дамжуулах чадвар хаагдсан (жишээ нь, pod-оос зангилаа руу, хонгилын хооронд эсвэл зангилаанаас IP pod руу ping хийх):
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
Дээрх тохиолдолд кластерийн зангилаанууд 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-ээр холбогдож, холбогдсон үед под болон үйлчилгээний кластерийн дэд сүлжээнүүдийн маршрутыг хүлээн авдаг. Дахин эхлүүлэх болон хаягийг өөрчлөх үед үйлчилгээгээ алдахгүйн тулд бүхэл бүтэн дэд сүлжээг түлхдэг.
Тохиргооны порт нь стандарт бөгөөд энэ нь програмыг тохируулах, Kubernetes кластер руу шилжүүлэх үйл явцад зарим нэг нюансуудыг бий болгодог. Жишээлбэл, ижил AWS LoadBalancer for UDP нь өнгөрсөн оны сүүлээр хязгаарлагдмал бүс нутгийн жагсаалтад гарч ирсэн бөгөөд NodePort нь бүх кластерийн зангилаанууд дээр дамжуулагдсан тул ашиглах боломжгүй бөгөөд серверийн жишээнүүдийн тоог масштаблах боломжгүй юм. алдааг тэсвэрлэх зорилготой. Дээрээс нь та портуудын өгөгдмөл мужийг өөрчлөх хэрэгтэй болно...
Боломжит шийдлүүдийг эрэлхийлсний үр дүнд дараахь зүйлийг сонгосон.
- VPN-тэй хонхорцог зангилаа бүрээр хуваарьтай
hostNetwork, өөрөөр хэлбэл бодит IP руу. - Үйлчилгээг дамжуулан гадна байрлуулсан байна
ClusterIP. Зангилаа дээр портыг физик байдлаар суулгасан бөгөөд бага зэрэг захиалгатай (бодит IP хаяг байгаа тохиолдолд) гаднаас хандах боломжтой. - Сарнай цэцгийн зангилааг тодорхойлох нь бидний түүхийн хүрээнээс гадуур юм. Та үйлчилгээг зангилаа руу чанга "хадаас" эсвэл VPN үйлчилгээний одоогийн IP хаягийг хянаж, үйлчлүүлэгчидтэй бүртгүүлсэн DNS бүртгэлийг засварлах жижиг хажуугийн үйлчилгээ бичиж болно гэж хэлье - хэн ч хангалттай төсөөлөлтэй байна.
Чиглүүлэлтийн үүднээс бид VPN клиентийг VPN серверээс олгосон IP хаягаар нь ялган таних боломжтой. Дээр дурдсан 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 үйлчилгээний үйл ажиллагаа хадгалагдан үлдсэн бөгөөд дүрэм боловсруулахад үйл ажиллагаа нь ихэвчлэн зовдог. Учир нь өмнө дурьдсанчлан сонгогч гарч ирэхэд өөрөөр заагаагүй бол өгөгдмөл үгүйсгэх бодлогыг хэрэгжүүлдэг.
Үр дүн
Тиймээс, Calico-н дэвшилтэт API-г ашиглан кластер доторх болон эргэн тойронд чиглүүлэлтээ уян хатан тохируулж, динамикаар өөрчлөх боломжтой. Ерөнхийдөө түүний хэрэглээ нь их буугаар бор шувуу буудаж байгаа мэт харагдах бөгөөд BGP болон IP-IP хонгил бүхий L3 сүлжээг хэрэгжүүлэх нь хавтгай сүлжээнд энгийн Kubernetes суулгацын хувьд аймшигтай харагддаг ... Гэсэн хэдий ч, өөрөөр хэлбэл энэ хэрэгсэл нь нэлээд боломжтой бөгөөд ашигтай харагдаж байна. .
Аюулгүй байдлын шаардлагыг хангахын тулд кластерыг тусгаарлах нь үргэлж боломжгүй байдаг бөгөөд энэ нь Калико (эсвэл ижил төстэй шийдэл) аврах ажилд ирдэг. Энэ нийтлэлд өгөгдсөн жишээнүүдийг (бага зэргийн өөрчлөлттэй) манай үйлчлүүлэгчдийн AWS-д хэд хэдэн суулгацад ашигласан болно.
PS
Мөн манай блог дээрээс уншина уу:
- «";
- "Кубернетес дэх сүлжээний зурагтай гарын авлага": , ;
- «".
Эх сурвалж: www.habr.com