Kubernetes тармагында Calico: киришүү жана бир аз тажрыйба

Макаланын максаты окурманды Кубернетестеги тармактык саясаттын негиздери жана башкаруу, ошондой эле стандарттык мүмкүнчүлүктөрдү кеңейткен үчүнчү тараптын Calico плагини менен тааныштыруу. Жолдо конфигурациянын жөнөкөйлүгү жана кээ бир мүмкүнчүлүктөр биздин иштөө тажрыйбабыздан реалдуу мисалдар менен көрсөтүлөт.

Kubernetes тармактык шайманына тез киришүү

Kubernetes кластерин тармаксыз элестетүү мүмкүн эмес. Биз алардын негиздери боюнча материалдарды буга чейин жарыялаганбыз: «Kubernetes тармагында иллюстрацияланган колдонмо"Ал эми"Коопсуздук адистери үчүн Kubernetes тармактык саясаттарына киришүү«.

Бул макаланын контекстинде, K8s өзү контейнерлер менен түйүндөрдүн ортосундагы тармактык байланыш үчүн жооптуу эмес экенин белгилей кетүү маанилүү: бул үчүн ар кандай CNI плагиндери (Container Networking Interface). Бул концепция тууралуу кененирээк биз мага да айтышты.

Мисалы, бул плагиндердин эң кеңири таралганы калыъ — ар бир түйүндө көпүрөлөрдү көтөрүү, ага субсеттерди ыйгаруу аркылуу бардык кластердик түйүндөр ортосунда толук тармактык байланышты камсыздайт. Бирок, толук жана жөнгө салынбаган жеткиликтүүлүк дайыма эле пайдалуу боло бербейт. Кластерде минималдуу изоляцияны камсыз кылуу үчүн брандмауэрдин конфигурациясына кийлигишүү керек. Жалпысынан алганда, ал ошол эле CNI көзөмөлү астында жайгаштырылат, ошондуктан iptables боюнча үчүнчү тараптын кийлигишүүсү туура эмес чечмелениши же таптакыр этибарга алынышы мүмкүн.

Жана Kubernetes кластеринде тармак саясатын башкарууну уюштуруу үчүн "кутудан тышкары" берилген 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 түрү бар экени логикалык: поддонго кирүү (Кирүү) жана андан чыгуу (Egress).

Чындыгында саясат кыймылдын багыты боюнча ушул 2 категорияга бөлүнөт.

Кийинки талап кылынган атрибут селектор болуп саналат; эреже кимге тиешелүү болсо. Бул подкаст (же подъезддердин тобу) же чөйрө (б.а. аттар мейкиндиги) болушу мүмкүн. Маанилүү детал: бул объекттердин эки түрү тең энбелгисин камтышы керек (этикетка Kubernetes терминологиясында) - бул саясатчылар менен иштешет.

Кандайдыр бир этикетка менен бириктирилген чектүү сандагы селекторлордон тышкары, ар кандай вариацияларда “Баарына/башкарууга/башкаруу” сыяктуу эрежелерди жазууга болот. Бул максатта формадагы конструкциялар колдонулат:

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

— бул мисалда айлана-чөйрөдөгү бардык поддондор кирген трафиктен бөгөттөлгөн. карама-каршы жүрүм-туруму төмөнкү курулуш менен жетишүүгө болот:

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

Ошо сыяктуу эле, чыгуу үчүн:

  podSelector: {}
  policyTypes:
  - Egress

- өчүрүү үчүн. Жана бул жерде төмөнкүлөрдү камтуу керек:

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

Кластер үчүн CNI плагинин тандоого кайрылып, муну белгилей кетүү керек ар бир тармак плагини NetworkPolicy колдой бербейт. Мисалы, буга чейин айтылган Фланел тармак саясатын кантип конфигурациялоону билбейт түз эле айтылат расмий репозиторийде. Ал жерде дагы альтернатива айтылган - Open Source долбоору Calico, бул тармак саясаттары жагынан Kubernetes API стандарттык топтомун бир топ кеңейтет.

Калико менен таанышуу: теория

Calico плагинин Flannel менен интеграциялоодо колдонсо болот (подпроект канал) же өз алдынча, тармак байланышын жана жеткиликтүүлүктү башкаруу мүмкүнчүлүктөрүн камтыйт.

K8s "кутуланган" чечимди жана Calico API топтомун колдонуу кандай мүмкүнчүлүктөрдү берет?

NetworkPolicyде эмнелер камтылган:

• саясатчылар чөйрө менен чектелген;
• саясаттар энбелгилер менен белгиленген уячаларга колдонулат;
• эрежелер подсткаларга, чөйрөлөргө же субсеттерге колдонулушу мүмкүн;
• эрежелер протоколдорду, аталган же символдук порт спецификацияларын камтышы мүмкүн.

Бул жерде Calico бул функцияларды кантип кеңейтет:

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

Calico репозиторийиндеги GitHub боюнча биринчи милдеттенмелер 2016-жылдын июль айына туура келет, ал эми бир жылдан кийин долбоор Kubernetes тармагынын байланышын уюштурууда алдыңкы позицияны ээледи - муну, мисалы, сурамжылоонун натыйжалары далилдеп турат, The New Stack тарабынан жүргүзүлгөн:

сыяктуу K8s менен көптөгөн ири башкарылган чечимдер Amazon EKS, Azure AKS, Google GKE жана башкалар аны пайдаланууга сунуш кыла башташты.

Ал эми аткарууга келсек, бул жерде баары сонун. Алардын продуктуну сыноодо, Calico иштеп чыгуу командасы секундасына 50000 контейнер түзүү ылдамдыгы менен 500 физикалык түйүндөрүндө 20ден ашык контейнерди иштетип, астрономиялык көрсөткүчтөрдү көрсөттү. Масштабда эч кандай көйгөйлөр аныкталган жок. Мындай натыйжалар жарыяланды биринчи версиясын жарыялоодо. Өткөрүү жөндөмдүүлүгүнө жана ресурсту керектөөгө багытталган көз карандысыз изилдөөлөр да Calicoнун көрсөткүчтөрү Фланелдикиндей жакшы экенин тастыктайт. Мисалы,:

Долбоор абдан тез өнүгүп жатат, ал K8s, OpenShift, OpenStack башкарылган популярдуу чечимдерде иштөөнү колдойт, кластерди колдонууда Calico колдонсо болот. коп, Service Mesh тармактарынын курулушуна шилтемелер бар (Бул жерде бир мисалы болуп саналат Istio менен бирге колдонулат).

Calico менен машыгыңыз

Vanilla Kubernetes колдонгон учурда, CNI орнотуу файлды колдонууга туура келет calico.yaml, расмий сайтынан жүктөлүп алынган, жардамы менен kubectl apply -f.

Эреже катары, плагиндин учурдагы версиясы Kubernetesтин акыркы 2-3 версиясына шайкеш келет: эски версияларда иштөө текшерилбейт жана кепилдик жок. Иштеп чыгуучулардын айтымында, Calico 3.10дон жогору Linux ядросунда CentOS 7, Ubuntu 16 же Debian 8, iptables же IPVS үстүнө иштейт.

Айлана-чөйрөнүн ичинде изоляция

Жалпы түшүнүк үчүн, 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 кутудан чыккан, бирок аны колдонууга эч нерсе тоскоол болбойт 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

Кадимки NetworkPolicy API аркылуу бардык трафикке уруксат берүү же четке кагуу үчүн жогоруда айтылган конструкциялар түшүнүү жана эстеп калуу кыйын болгон кашаалар менен курулмаларды камтыйт. Calico учурда, брандмауэр эрежесинин логикасын тескерисинче өзгөртүү үчүн, жөн гана өзгөртүңүз action: Allow боюнча action: Deny.

Айлана-чөйрө боюнча изоляция

Эми Прометейде чогултуу жана 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 объекттерин колдонуу

Эсиңиздерге сала кетейин, 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 Case

Акыр-аягы, мен стандарттуу саясаттар топтому жетишсиз болгондо, кластерге жакын өз ара аракеттенүү үчүн Calico функцияларын колдонуунун реалдуу мисалын берем. Веб тиркемеге кирүү үчүн кардарлар VPN туннелин колдонушат жана бул кирүү катуу көзөмөлгө алынат жана колдонууга уруксат берилген кызматтардын белгилүү бир тизмеси менен чектелет:

Кардарлар VPNге стандарттуу UDP порту 1194 аркылуу туташат жана туташкандан кийин подкасттардын жана кызматтардын кластердик ички тармактарына маршруттарды алышат. Даректерди өчүрүп-күйгүзүүдө жана өзгөртүүдө кызматтарды жоготуп албаш үчүн бүт субторлор түртүлөт.

Конфигурациядагы порт стандарттуу, ал тиркемени конфигурациялоо жана аны Kubernetes кластерине өткөрүү процессине айрым нюанстарды жүктөйт. Мисалы, ошол эле AWS LoadBalancer үчүн UDP өткөн жылдын аягында түзмө-түз аймактардын чектелген тизмесинде пайда болгон жана NodePort анын бардык кластердик түйүндөрдө багыттоосунан улам колдонулбайт жана сервердик инстанциялардын санын масштабдоо мүмкүн эмес. каталарга чыдамдуулук максаттары. Мындан тышкары, сиз порттордун демейки диапазонун өзгөртүүгө туура келет ...

Мүмкүн болгон чечимдерди издөөнүн натыйжасында төмөндөгүлөр тандалды:

1. VPN менен поддондор ар бир түйүнгө пландаштырылган hostNetwork, башкача айтканда, чыныгы IP.
2. Кызмат аркылуу сыртка жайгаштырылат ClusterIP. Түйүнгө порт физикалык түрдө орнотулган, ал сырттан анча-мынча резервдер менен жеткиликтүү (чыныгы IP даректин шарттуу болушу).
3. Подгон гүлүнүн түйүнүн аныктоо биздин окуянын чегинен тышкары. Мен жөн гана айта кетейин, сиз кызматты түйүнгө бекем "тырмак" же кичинекей каптал кызматын жаза аласыз, ал 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 орнотуусунда укмуштуудай көрүнөт... .

Коопсуздук талаптарына жооп берүү үчүн кластерди обочолонтуу дайыма эле мүмкүн боло бербейт жана бул жерде Calico (же ушуга окшош чечим) жардамга келет. Бул макалада келтирилген мисалдар (кичинекей өзгөртүүлөр менен) биздин кардарлардын AWSдеги бир нече орнотууларында колдонулат.

PS

Биздин блогдон дагы окуңуз:

• «Коопсуздук адистери үчүн Kubernetes тармактык саясаттарына киришүү";
• "Kubernetes тармагында иллюстрацияланган колдонмо": 1 жана 2 бөлүктөрү (тармак модели, кабаттуу тармактар), 3-бөлүк (кызматтар жана трафикти иштетүү);
• «Container Networking Interface (CNI) - тармак интерфейси жана Linux контейнерлери үчүн стандарт«.

Source: www.habr.com