Kubernetesdə şəbəkə qurmaq üçün Calico: giriş və bir az təcrübə

Məqalənin məqsədi oxucunu Kubernetes-də şəbəkə qurmağın və şəbəkə siyasətinin idarə edilməsinin əsasları, eləcə də standart imkanları genişləndirən üçüncü tərəf Calico plaginini təqdim etməkdir. Yol boyu, konfiqurasiya asanlığı və bəzi xüsusiyyətlər əməliyyat təcrübəmizdən real nümunələrdən istifadə etməklə nümayiş etdiriləcək.

Kubernetes şəbəkə cihazına sürətli giriş

Kubernetes klasterini şəbəkəsiz təsəvvür etmək olmaz. Biz artıq onların əsasları haqqında materiallar dərc etmişik: “Kubernetes-də şəbəkə qurmaq üçün təsvir edilmiş bələdçi"Və"Təhlükəsizlik Peşəkarları üçün Kubernetes Şəbəkə Siyasətlərinə Giriş.

Bu məqalənin kontekstində qeyd etmək lazımdır ki, K8-in özü konteynerlər və qovşaqlar arasında şəbəkə bağlantısı üçün məsuliyyət daşımır: bunun üçün müxtəlif CNI plaginləri (Konteyner Şəbəkə İnterfeysi). Bu konsepsiya haqqında daha çox mənə də dedilər.

Məsələn, bu plaginlərdən ən çox yayılmışı Flanel — hər qovşaqda körpülər qaldıraraq, ona alt şəbəkə təyin etməklə bütün klaster qovşaqları arasında tam şəbəkə bağlantısını təmin edir. Bununla belə, tam və tənzimlənməmiş əlçatanlıq həmişə faydalı olmur. Klasterdə bir növ minimal izolyasiya təmin etmək üçün təhlükəsizlik duvarının konfiqurasiyasına müdaxilə etmək lazımdır. Ümumi halda, o, eyni CNI-nin nəzarəti altında yerləşdirilir, buna görə də iptables-ə hər hansı üçüncü tərəf müdaxilələri səhv şərh edilə bilər və ya ümumiyyətlə nəzərə alınmır.

Kubernetes klasterində şəbəkə siyasətinin idarə edilməsini təşkil etmək üçün "qutudan kənar" təmin edilir NetworkPolicy API. Seçilmiş ad məkanları üzərində paylanmış bu resurs bir tətbiqdən digərinə girişi fərqləndirmək üçün qaydalar ehtiva edə bilər. O, həmçinin xüsusi podlar, mühitlər (ad boşluqları) və ya IP ünvan blokları arasında əlçatanlığı konfiqurasiya etməyə imkan verir:

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

Bu, ən primitiv nümunə deyil rəsmi sənədlər şəbəkə siyasətlərinin necə işlədiyinin məntiqini anlamaq istəyini birdəfəlik azalda bilər. Bununla belə, biz yenə də şəbəkə siyasətlərindən istifadə edərək trafik axınlarının işlənməsinin əsas prinsiplərini və üsullarını anlamağa çalışacağıq...

Məntiqlidir ki, 2 növ trafik var: poda daxil olmaq (Giriş) və ondan çıxan (Egress).

Əslində siyasət hərəkət istiqamətinə görə bu 2 kateqoriyaya bölünür.

Növbəti tələb olunan atribut seçicidir; qaydanın tətbiq olunduğu şəxs. Bu, pod (və ya bir qrup pod) və ya mühit (yəni ad sahəsi) ola bilər. Vacib bir detal: bu obyektlərin hər iki növü etiketdən ibarət olmalıdır (etiket Kubernetes terminologiyasında) - siyasətçilərin işlədikləri bunlardır.

Bir növ etiketlə birləşdirilən məhdud sayda seçicilərə əlavə olaraq, müxtəlif variasiyalarda “Hər şeyə/hər kəsə icazə ver/inkar et” kimi qaydaları yazmaq mümkündür. Bu məqsədlə formanın konstruksiyalarından istifadə olunur:

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

— bu nümunədə ətrafdakı bütün podlar gələn trafikdən bloklanır. Əks davranış aşağıdakı tikinti ilə əldə edilə bilər:

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

Eynilə, gedənlər üçün:

  podSelector: {}
  policyTypes:
  - Egress

- söndürmək üçün. Və burada nə daxil edilməlidir:

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

Bir klaster üçün CNI plagininin seçiminə qayıdaraq, qeyd etmək lazımdır hər şəbəkə plagini NetworkPolicy-ni dəstəkləmir. Məsələn, artıq qeyd olunan Flanel şəbəkə siyasətini necə konfiqurasiya edəcəyini bilmir birbaşa deyilir rəsmi depoda. Orada bir alternativ də qeyd olunur - Açıq Mənbə layihəsi kolenkor, bu, şəbəkə siyasətləri baxımından Kubernetes API-lərinin standart dəstini əhəmiyyətli dərəcədə genişləndirir.

Calico ilə tanış olmaq: nəzəriyyə

Calico plagini Flannel ilə inteqrasiyada istifadə edilə bilər (alt layihə Kanal) və ya müstəqil olaraq həm şəbəkə bağlantısı, həm də əlçatanlığın idarə edilməsi imkanlarını əhatə edir.

K8s "qutulu" həlli və Calico-dan API dəsti istifadə edərək hansı imkanları təmin edir?

NetworkPolicy-də qurulan budur:

• siyasətçilər ətraf mühitlə məhdudlaşır;
• siyasətlər etiketlərlə işarələnmiş podlara tətbiq edilir;
• qaydalar podlara, mühitlərə və ya alt şəbəkələrə tətbiq edilə bilər;
• qaydalar protokolları, adlandırılmış və ya simvolik port spesifikasiyalarını ehtiva edə bilər.

Calico bu funksiyaları necə genişləndirir:

• siyasətlər istənilən obyektə tətbiq oluna bilər: pod, konteyner, virtual maşın və ya interfeys;
• qaydalar müəyyən bir hərəkəti ehtiva edə bilər (qadağa, icazə, giriş);
• hədəf və ya qaydaların mənbəyi port, bir sıra portlar, protokollar, HTTP və ya ICMP atributları, IP və ya alt şəbəkə (4-cü və ya 6-cı nəsil), istənilən seçicilər (qovşaqlar, hostlar, mühitlər) ola bilər;
• Əlavə olaraq, siz DNAT parametrləri və trafik yönləndirmə siyasətlərindən istifadə edərək trafikin keçidini tənzimləyə bilərsiniz.

Calico deposunda GitHub-da ilk öhdəliklər 2016-cı ilin iyul ayına təsadüf edir və bir il sonra layihə Kubernetes şəbəkə bağlantısının təşkilində aparıcı mövqe tutdu - bunu, məsələn, sorğunun nəticələri sübut edir, The New Stack tərəfindən aparılır:

K8-lər ilə bir çox böyük idarə olunan həllər, məsələn Amazon EKS, Azure AKS, Google GKE və başqaları istifadə üçün tövsiyə etməyə başladılar.

Performansa gəlincə, burada hər şey əladır. Məhsullarını sınaqdan keçirərkən, Calico inkişaf komandası saniyədə 50000 konteyner yaratma sürəti ilə 500 fiziki qovşaqda 20-dən çox konteyner işlədən astronomik performans nümayiş etdirdi. Ölçmə ilə bağlı heç bir problem müəyyən edilmədi. Belə nəticələr elan edildi artıq birinci versiyanın elanında. Ötürmə qabiliyyətinə və resurs istehlakına yönəlmiş müstəqil tədqiqatlar da Calico-nun performansının Flannel-inki qədər yaxşı olduğunu təsdiqləyir. Məsələn:

Layihə çox sürətlə inkişaf edir, K8s, OpenShift, OpenStack tərəfindən idarə olunan məşhur həllərdə işləməyi dəstəkləyir, klasteri yerləşdirərkən Calico-dan istifadə etmək mümkündür. qəpik, Service Mesh şəbəkələrinin qurulmasına istinadlar var (burada bir nümunə var Istio ilə birlikdə istifadə olunur).

Calico ilə məşq edin

Vanil Kubernetes istifadəsinin ümumi vəziyyətində, CNI-nin quraşdırılması fayldan istifadə etməyə gəlir calico.yaml, rəsmi saytından endirilib, istifadə edərək kubectl apply -f.

Bir qayda olaraq, plaqinin cari versiyası Kubernetes-in ən son 2-3 versiyasına uyğun gəlir: köhnə versiyalarda işləmə sınaqdan keçirilmir və zəmanət verilmir. Tərtibatçıların fikrincə, Calico iptables və ya IPVS-in üstündə CentOS 3.10, Ubuntu 7 və ya Debian 16 ilə işləyən 8-dan yuxarı Linux nüvələrində işləyir.

Ətraf mühitdə izolyasiya

Ümumi başa düşmək üçün Calico notasiyasındakı şəbəkə siyasətlərinin standartlardan necə fərqləndiyini və qaydaların yaradılmasına yanaşmanın onların oxunaqlılığını və konfiqurasiya çevikliyini necə asanlaşdırdığını başa düşmək üçün sadə bir vəziyyətə baxaq:

Klasterdə yerləşdirilmiş 2 veb proqram var: Node.js və PHP-də, onlardan biri Redis-dən istifadə edir. Node.js ilə əlaqə saxlamaqla PHP-dən Redis-ə girişi bloklamaq üçün aşağıdakı siyasəti tətbiq etmək kifayətdir:

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

Əslində biz Node.js-dən Redis portuna gələn trafikə icazə verdik. Və açıq şəkildə başqa heç nəyi qadağan etmədilər. NetworkPolicy görünən kimi, başqa cür göstərilmədiyi təqdirdə, orada qeyd olunan bütün seçicilər təcrid olunmağa başlayır. Bununla belə, izolyasiya qaydaları selektorun əhatə etmədiyi digər obyektlərə şamil edilmir.

Nümunə istifadə edir apiVersion Kubernetes qutudan çıxdı, lakin heç bir şey istifadə etməyinizə mane olmur Calico çatdırılmasından eyni adlı resurs. Oradakı sintaksis daha təfərrüatlıdır, ona görə də yuxarıdakı hal üçün qaydanı aşağıdakı formada yenidən yazmalısınız:

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

Adi NetworkPolicy API vasitəsilə bütün trafikə icazə vermək və ya rədd etmək üçün yuxarıda qeyd olunan konstruksiyalar başa düşmək və yadda saxlamaq çətin olan mötərizəli konstruksiyaları ehtiva edir. Calico vəziyyətində, bir firewall qaydasının məntiqini əksinə dəyişdirmək üçün sadəcə dəyişdirin action: Allow haqqında action: Deny.

Ətraf mühitə görə izolyasiya

İndi tətbiqin Prometheus-da toplanması və Grafana-dan istifadə edərək sonrakı təhlil üçün biznes ölçülərini yaratdığı bir vəziyyəti təsəvvür edin. Yükləmədə defolt olaraq yenidən ictimaiyyət üçün görünən həssas data ola bilər. Gəlin bu məlumatları maraqlı gözlərdən gizlədək:

Prometey, bir qayda olaraq, ayrı bir xidmət mühitində yerləşdirilir - nümunədə bu, belə bir ad sahəsi olacaqdır:

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

Sahə metadata.labels bunun təsadüf olmadığı ortaya çıxdı. Yuxarıda qeyd edildiyi kimi, namespaceSelector (eləcə də podSelector) etiketlərlə işləyir. Buna görə də, müəyyən bir portdakı bütün podlardan ölçülərin götürülməsinə icazə vermək üçün bir növ etiket əlavə etməli (və ya mövcud olanlardan götürməli) və sonra belə bir konfiqurasiya tətbiq etməlisiniz:

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 siyasətlərindən istifadə etsəniz, sintaksis belə olacaq:

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

Ümumiyyətlə, xüsusi ehtiyaclar üçün bu cür siyasətləri əlavə etməklə siz klasterdəki proqramların işinə zərərli və ya təsadüfi müdaxilədən qoruya bilərsiniz.

Calico yaradıcılarının fikrincə, ən yaxşı təcrübə “Hər şeyi bloklayın və sizə lazım olanı açıq şəkildə açın” yanaşmasıdır. rəsmi sənədlər (digərləri oxşar yanaşmaya əməl edirlər - xüsusən də artıq qeyd olunan məqalə).

Əlavə Calico Obyektlərindən istifadə

Nəzərinizə çatdırım ki, Calico API-lərinin genişləndirilmiş dəsti vasitəsilə siz qovşaqlarla məhdudlaşmayaraq, qovşaqların mövcudluğunu tənzimləyə bilərsiniz. Aşağıdakı nümunədə istifadə edərək GlobalNetworkPolicy klasterdə ICMP sorğularını ötürmək imkanı bağlanır (məsələn, poddan qovşağa, podlar arasında və ya qovşaqdan IP poduna pinglər):

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

Yuxarıdakı vəziyyətdə, klaster qovşaqlarının ICMP vasitəsilə bir-birinə “çatması” hələ də mümkündür. Və bu məsələ vasitələrlə həll olunur GlobalNetworkPolicy, müəssisəyə tətbiq edilir 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 işi

Nəhayət, standart siyasət dəsti kifayət etmədikdə, klasterə yaxın qarşılıqlı əlaqə üçün Calico funksiyalarından istifadənin çox real nümunəsini verəcəyəm. Veb tətbiqinə daxil olmaq üçün müştərilər VPN tunelindən istifadə edirlər və bu giriş ciddi şəkildə idarə olunur və istifadəyə icazə verilən xidmətlərin xüsusi siyahısı ilə məhdudlaşır:

Müştərilər standart UDP portu 1194 vasitəsilə VPN-ə qoşulur və qoşulduqda podların və xidmətlərin klaster alt şəbəkələrinə marşrutlar alırlar. Yenidən başlatma və ünvan dəyişiklikləri zamanı xidmətləri itirməmək üçün bütün alt şəbəkələr itələnir.

Konfiqurasiyadakı port standartdır, bu, tətbiqin konfiqurasiyası və Kubernetes klasterinə ötürülməsi prosesinə bəzi nüanslar qoyur. Məsələn, UDP üçün eyni AWS LoadBalancer sözün həqiqi mənasında keçən ilin sonunda məhdud bölgələr siyahısında ortaya çıxdı və NodePort bütün klaster qovşaqlarında yönləndirilməsi səbəbindən istifadə edilə bilməz və server nümunələrinin sayını miqyaslaşdırmaq mümkün deyil. səhvlərə dözümlülük məqsədləri. Üstəlik, standart port diapazonunu dəyişməli olacaqsınız...

Mümkün həllərin axtarışı nəticəsində aşağıdakılar seçildi:

1. VPN ilə podlar hər bir node üçün planlaşdırılıb hostNetwork, yəni faktiki IP-yə.
2. Xidmət vasitəsilə kənarda yerləşdirilir ClusterIP. Kiçik rezervasiyalarla xaricdən əldə edilə bilən (həqiqi IP ünvanının şərti olması) qovşaqda fiziki olaraq bir port quraşdırılmışdır.
3. Pod gülünün hansı düyünün müəyyən edilməsi hekayəmizin əhatə dairəsindən kənardadır. Sadəcə deyəcəyəm ki, xidməti bir qovşaqda möhkəm "mixlaya" və ya VPN xidmətinin cari IP ünvanını izləyəcək və müştərilərlə qeydiyyatdan keçmiş DNS qeydlərini redaktə edəcək kiçik bir yan xidmət yaza bilərsiniz - kimin kifayət qədər təsəvvürü varsa.

Marşrutlaşdırma nöqteyi-nəzərindən biz VPN müştərisini VPN serveri tərəfindən verilmiş IP ünvanı ilə unikal şəkildə müəyyən edə bilərik. Aşağıda yuxarıda qeyd olunan Redis-də təsvir edilmiş belə bir müştərinin xidmətlərə çıxışını məhdudlaşdıran primitiv nümunə verilmişdir:

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]

Burada 6379 portuna qoşulmaq qəti qadağandır, lakin eyni zamanda qaydaları tərtib edərkən işləməsi çox vaxt əziyyət çəkən DNS xidmətinin fəaliyyəti qorunur. Çünki, əvvəl qeyd edildiyi kimi, seçici görünəndə, başqa cür göstərilmədiyi təqdirdə, defolt inkar siyasəti ona tətbiq edilir.

Nəticələri

Beləliklə, Calico-nun təkmil API-dən istifadə edərək, siz klasterdə və ətrafında marşrutlaşdırmanı çevik şəkildə konfiqurasiya edə və dinamik şəkildə dəyişə bilərsiniz. Ümumiyyətlə, onun istifadəsi topla sərçələri vurmaq kimi görünə bilər və BGP və IP-IP tunelləri ilə L3 şəbəkəsinin həyata keçirilməsi düz şəbəkədə sadə Kubernetes quraşdırmasında dəhşətli görünür... Lakin, əks halda alət kifayət qədər səmərəli və faydalı görünür. .

Təhlükəsizlik tələblərinə cavab vermək üçün klasteri təcrid etmək həmişə mümkün olmaya bilər və burada Calico (və ya oxşar həll) xilasetmə üçün gəlir. Bu məqalədə verilən nümunələr (kiçik dəyişikliklərlə) müştərilərimizin AWS-də bir neçə quraşdırmasında istifadə olunur.

PS

Bloqumuzda da oxuyun:

• «Təhlükəsizlik Peşəkarları üçün Kubernetes Şəbəkə Siyasətlərinə Giriş";
• "Kubernetes-də Şəbəkə üçün İllüstrasiyalı Bələdçi": hissə 1 və 2 (şəbəkə modeli, üst-üstə düşən şəbəkələr), hissə 3 (xidmətlər və trafikin işlənməsi);
• «Konteyner Şəbəkə İnterfeysi (CNI) - şəbəkə interfeysi və Linux konteynerləri üçün standart.

Mənbə: www.habr.com