Калико за вмрежување во Кубернетес: вовед и малку искуство

Целта на статијата е да го запознае читателот со основите на вмрежувањето и управувањето со мрежните политики во Kubernetes, како и со додатокот Calico од трета страна кој ги проширува стандардните можности. На патот, леснотијата на конфигурација и некои карактеристики ќе се демонстрираат користејќи вистински примери од нашето оперативно искуство.

Брз вовед во мрежниот апарат Кубернетес

Кластерот Kubernetes не може да се замисли без мрежа. Веќе објавивме материјали за нивните основи: “Илустриран водич за вмрежување во Кубернетес"И"Вовед во мрежните политики на Кубернетес за професионалци за безбедност".

Во контекст на овој напис, важно е да се забележи дека самиот K8s не е одговорен за мрежното поврзување помеѓу контејнерите и јазлите: за ова, различни CNI приклучоци (Интерфејс за вмрежување на контејнерите). Повеќе за овој концепт ние ми кажаа и тие.

На пример, најчестиот од овие приклучоци е Фланел — обезбедува целосна мрежна конекција помеѓу сите јазли на кластери со подигање мостови на секој јазол, доделувајќи му подмрежа. Сепак, целосната и нерегулирана пристапност не е секогаш корисна. За да се обезбеди некаква минимална изолација во кластерот, потребно е да се интервенира во конфигурацијата на заштитниот ѕид. Во општиот случај, тој е ставен под контрола на истиот CNI, поради што сите интервенции од трета страна во iptables може да се толкуваат погрешно или целосно да се игнорираат.

Обезбедено е и „надвор од кутијата“ за организирање на управување со мрежни политики во кластер на Кубернетес NetworkPolicy API. Овој ресурс, дистрибуиран преку одбрани именски простори, може да содржи правила за да се разликува пристапот од една апликација до друга. Исто така, ви овозможува да ја конфигурирате пристапноста помеѓу одредени подлоги, околини (именски простори) или блокови од 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) и излегување од него (Излез).

Всушност, политиката е поделена на овие две категории врз основа на насоката на движење.

Следниот потребен атрибут е селектор; оној за кој важи правилото. Ова може да биде pod (или група на pods) или околина (т.е. именски простор). Важен детал: двата типа на овие објекти мора да содржат етикета (етикета во терминологијата на Кубернет) - тоа се оние со кои оперираат политичарите.

Покрај конечен број на избирачи обединети со некаква ознака, можно е да се напишат правила како „Дозволи/одби се/секој“ во различни варијации. За таа цел се користат конструкции од формата:

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

— во овој пример, сите подлоги во околината се блокирани од дојдовниот сообраќај. Спротивното однесување може да се постигне со следната конструкција:

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

Слично за појдовни:

  podSelector: {}
  policyTypes:
  - Egress

- да го исклучите. И еве што да вклучите:

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

Враќајќи се на изборот на CNI приклучок за кластер, вреди да се забележи дека не секој мрежен приклучок поддржува NetworkPolicy. На пример, веќе споменатиот Flannel не знае како да ги конфигурира мрежните политики, кои директно се вели во официјалното складиште. Таму се споменува и алтернатива - проект со отворен код Американ, што значително го проширува стандардниот сет на Kubernetes API во однос на мрежните политики.

Запознавање со Калико: теорија

Приклучокот Calico може да се користи во интеграција со Flannel (подпроект Канал) или независно, покривајќи ги и мрежното поврзување и способностите за управување со достапноста.

Какви можности дава користењето на K8s „boxed“ решението и API сетот од Calico?

Еве што е вградено во NetworkPolicy:

• политичарите се ограничени од околината;
• политиките се применуваат на мешунките означени со етикети;
• правилата може да се применат на подови, околини или подмрежи;
• правилата може да содржат протоколи, именувани или симболични спецификации на портата.

Еве како Calico ги проширува овие функции:

• политиките може да се применат на кој било објект: под, контејнер, виртуелна машина или интерфејс;
• правилата може да содржат одредена акција (забрана, дозвола, сеча);
• целта или изворот на правила може да биде порта, опсег на порти, протоколи, HTTP или ICMP атрибути, IP или подмрежа (четврта или 4-та генерација), какви било селектори (јазли, хостови, околини);
• Дополнително, можете да го регулирате поминувањето на сообраќајот користејќи ги поставките за DNAT и политиките за пренасочување на сообраќајот.

Првите обврски на GitHub во складиштето Calico датираат од јули 2016 година, а една година подоцна проектот зазеде водечка позиција во организирањето на мрежното поврзување на Kubernetes - ова е потврдено, на пример, со резултатите од истражувањето, спроведено од The ​​New Stack:

Многу големи управувани решенија со K8, како на пр Амазон ЕКС, Азур АКС, Google GKE а други почнаа да го препорачуваат за употреба.

Што се однесува до перформансите, овде се е одлично. При тестирањето на нивниот производ, тимот за развој на Calico покажа астрономски перформанси, управувајќи повеќе од 50000 контејнери на 500 физички јазли со брзина на создавање од 20 контејнери во секунда. Не беа идентификувани проблеми со скалирање. Вакви резултати беа објавени веќе на најава за првата верзија. Независните студии кои се фокусираат на пропусната моќ и потрошувачката на ресурси исто така потврдуваат дека перформансите на Calico се речиси исто толку добри како оние на Flannel. На пример:

Проектот се развива многу брзо, поддржува работа во популарни решенија управувани K8s, OpenShift, OpenStack, можно е да се користи Calico при распоредување кластер користејќи копс, постојат референци за изградбата на Service Mesh мрежи (Еве еден пример се користи заедно со Istio).

Вежбајте со Calico

Во општиот случај на користење на Kubernetes од ванила, инсталирањето на CNI се сведува на користење на датотеката calico.yaml, преземено од официјалната веб-страница, со користење на kubectl apply -f.

Како по правило, тековната верзија на приклучокот е компатибилна со најновите 2-3 верзии на Kubernetes: работата во постарите верзии не е тестирана и не е загарантирана. Според програмерите, Calico работи на Linux кернели над 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

Во суштина, дозволивме дојдовен сообраќај до пристаништето Редис од Node.js. И тие очигледно не забранија ништо друго. Штом се појави 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.

Изолација според околината

Сега замислете ситуација кога апликацијата генерира деловни метрики за собирање во Прометеј и понатамошна анализа со помош на Графана. Поставувањето може да содржи чувствителни податоци, кои стандардно повторно се јавно видливи. Ајде да ги скриеме овие податоци од љубопитните очи:

Прометеј, по правило, се става во посебна опкружување за услуги - во примерот ќе биде именски простор како овој:

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 барања во кластерот е затворена (на пример, пинг од под до јазол, помеѓу подови или од јазол до 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

Во горенаведениот случај, сè уште е можно јазлите на кластерите да „посегнат“ еден до друг преку 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 за UDP се појави буквално на крајот на минатата година во ограничен список на региони, а NodePort не може да се користи поради неговото проследување на сите јазли на кластерот и невозможно е да се скалира бројот на примероци на сервер за цели за толеранција на грешки. Плус, ќе треба да го промените стандардниот опсег на порти...

Како резултат на пребарување на можни решенија, беше избрано следново:

1. Подовите со VPN се закажани по јазол во hostNetwork, односно до вистинската IP адреса.
2. Услугата е објавена надвор преку ClusterIP. На јазолот е физички инсталирана порта, која е достапна однадвор со мали резервации (условно присуство на вистинска IP адреса).
3. Одредувањето на јазолот на кој се зголемила мешунката е надвор од опсегот на нашата приказна. Само ќе кажам дека можете цврсто да ја „заковате“ услугата на јазол или да напишете мала услуга за странична лента што ќе ја следи тековната 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 изгледа монструозно во едноставна инсталација на Кубернетес на рамна мрежа... Меѓутоа, инаку алатката изгледа доста остварлива и корисна .

Изолирањето на кластерот за да се исполнат безбедносните барања можеби не е секогаш изводливо, и токму тука Calico (или слично решение) доаѓа на помош. Примерите дадени во овој напис (со мали измени) се користат во неколку инсталации на нашите клиенти во AWS.

PS

Прочитајте и на нашиот блог:

• «Вовед во мрежните политики на Кубернетес за професионалци за безбедност";
• „Илустриран водич за вмрежување во Кубернетес“: делови 1 и 2 (мрежен модел, преклопени мрежи), дел 3 (услуги и сообраќајна обработка);
• «Контејнерски мрежен интерфејс (CNI) - мрежен интерфејс и стандард за контејнери за Linux".

Извор: www.habr.com