Calico за работа в мрежа в Kubernetes: въведение и малко опит

Целта на статията е да запознае читателя с основите на работата в мрежа и управлението на мрежовите политики в Kubernetes, както и с приставката Calico на трета страна, която разширява стандартните възможности. По пътя, леснотата на конфигуриране и някои функции ще бъдат демонстрирани с помощта на реални примери от нашия оперативен опит.

Кратко въведение в мрежовото устройство Kubernetes

Клъстер на Kubernetes не може да се представи без мрежа. Вече публикувахме материали за техните основи: „Илюстровано ръководство за работа в мрежа в Kubernetes"И"Въведение в мрежовите политики на Kubernetes за специалисти по сигурността".

В контекста на тази статия е важно да се отбележи, че самият K8s не е отговорен за мрежовата свързаност между контейнери и възли: за това различни CNI добавки (Мрежов интерфейс на контейнер). Повече за тази концепция ние също ми казаха.

Например, най-често срещаният от тези добавки е бархет — осигурява пълна мрежова свързаност между всички възли на клъстера чрез издигане на мостове на всеки възел, присвояване на подмрежа към него. Но пълната и нерегламентирана достъпност не винаги е от полза. За да се осигури някаква минимална изолация в клъстера, е необходимо да се намеси в конфигурацията на защитната стена. В общия случай той е поставен под контрола на същия CNI, поради което всякакви намеси на трети страни в iptables могат да бъдат интерпретирани неправилно или напълно игнорирани.

Предоставя се „извън кутията“ за организиране на управление на мрежови политики в клъстер на Kubernetes API на NetworkPolicy. Този ресурс, разпределен в избрани пространства от имена, може да съдържа правила за разграничаване на достъпа от едно приложение към друго. Той също така ви позволява да конфигурирате достъпност между конкретни подове, среди (именни пространства) или блокове от 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

Връщайки се към избора на CNI плъгин за клъстер, заслужава да се отбележи, че не всеки мрежов плъгин поддържа NetworkPolicy. Например, вече споменатият Flannel не знае как да конфигурира мрежови политики, които казано е директно в официалното хранилище. Там се споменава и алтернатива – проект с отворен код американ, което значително разширява стандартния набор от API на Kubernetes по отношение на мрежовите политики.

Запознаване с Calico: теория

Приставката Calico може да се използва в интеграция с Flannel (подпроект Канал) или независимо, обхващайки както мрежовата свързаност, така и възможностите за управление на наличността.

Какви възможности предоставя използването на „опакованото“ решение на K8s и набора API от Calico?

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

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

Ето как Calico разширява тези функции:

• политиките могат да се прилагат към всеки обект: pod, контейнер, виртуална машина или интерфейс;
• правилата могат да съдържат конкретно действие (забрана, разрешение, регистриране);
• целта или източникът на правила може да бъде порт, набор от портове, протоколи, HTTP или ICMP атрибути, IP или подмрежа (4-то или 6-то поколение), всякакви селектори (възли, хостове, среди);
• Освен това можете да регулирате преминаването на трафик, като използвате настройките на DNAT и правилата за пренасочване на трафика.

Първите ангажименти на GitHub в хранилището на Calico датират от юли 2016 г., а година по-късно проектът зае водеща позиция в организирането на мрежовата свързаност на Kubernetes - това се доказва например от резултатите от проучването, проведено от The New Stack:

Много големи управлявани решения с K8, като напр Amazon EKS, Azure AKS, Google GKE и други започнаха да го препоръчват за употреба.

Що се отнася до производителността, тук всичко е страхотно. При тестването на своя продукт екипът за разработка на Calico демонстрира астрономическа производителност, работейки с повече от 50000 500 контейнера на 20 физически възела със скорост на създаване от XNUMX контейнера в секунда. Не са установени проблеми с мащабирането. Такива резултати бяха обявени още при обявяването на първата версия. Независими проучвания, фокусирани върху производителността и консумацията на ресурси, също потвърждават, че производителността на 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

По същество ние разрешихме входящ трафик към порта на Redis от Node.js. И явно не са забранили нищо друго. Веднага щом се появи NetworkPolicy, всички селектори, споменати в него, започват да се изолират, освен ако не е указано друго. Правилата за изолация обаче не се прилагат за други обекти, които не са обхванати от селектора.

Примерът използва apiVersion Kubernetes е готов, но нищо не ви пречи да го използвате ресурс със същото име от доставката Calico. Синтаксисът там е по-подробен, така че ще трябва да пренапишете правилото за горния случай в следната форма:

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

Гореспоменатите конструкции за разрешаване или отказ на целия трафик през обикновения API на NetworkPolicy съдържат конструкции със скоби, които са трудни за разбиране и запомняне. В случая с Calico, за да промените логиката на правилото на защитната стена на обратното, просто променете action: Allow на action: Deny.

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

Сега си представете ситуация, в която приложение генерира бизнес показатели за събиране в Prometheus и допълнителен анализ с помощта на Grafana. Качването може да съдържа чувствителни данни, които отново са обществено видими по подразбиране. Нека скрием тези данни от любопитни очи:

Prometheus, като правило, се поставя в отделна сервизна среда - в примера това ще бъде пространство от имена като това:

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 обекти

Позволете ми да ви напомня, че чрез разширения набор от API на Calico можете да регулирате наличността на възли, без да се ограничавате до pods. В следващия пример с помощта GlobalNetworkPolicy възможността за предаване на ICMP заявки в клъстера е затворена (например ping от под към възел, между подове или от възел към 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 тунели изглежда чудовищно в проста инсталация на Kubernetes в плоска мрежа... В противен случай обаче инструментът изглежда доста жизнеспособен и полезен .

Изолирането на клъстер, за да отговаря на изискванията за сигурност, може да не винаги е осъществимо и тук Calico (или подобно решение) идва на помощ. Примерите, дадени в тази статия (с малки модификации), се използват в няколко инсталации на наши клиенти в AWS.

PS

Прочетете също в нашия блог:

• «Въведение в мрежовите политики на Kubernetes за специалисти по сигурността»;
• „Илюстровано ръководство за работа в мрежа в Kubernetes“: части 1 и 2 (мрежов модел, мрежи с наслагване), част 3 (услуги и обработка на трафик);
• «Container Networking Interface (CNI) - мрежов интерфейс и стандарт за Linux контейнери".

Източник: www.habr.com