Сврха чланка је да упозна читаоца са основама умрежавања и управљања мрежним политикама у Кубернетес-у, као и са Цалицо додатком треће стране који проширује стандардне могућности. Успут, лакоћа конфигурације и неке карактеристике ће бити демонстриране на стварним примерима из нашег радног искуства.
Кратак увод у Кубернетес мрежни уређај
Кубернетес кластер се не може замислити без мреже. Већ смо објавили материјале о њиховим основама: „"И"'.
У контексту овог чланка, важно је напоменути да сам К8с није одговоран за мрежну повезаност између контејнера и чворова: за то су различити ЦНИ додаци (Интерфејс за умрежавање контејнера). Више о овом концепту ми .
На пример, најчешћи од ових додатака је — обезбеђује потпуну мрежну повезаност између свих чворова кластера подизањем мостова на сваком чвору, додељујући му подмрежу. Међутим, потпуна и нерегулисана доступност није увек корисна. Да би се обезбедила нека врста минималне изолације у кластеру, потребно је интервенисати у конфигурацији заштитног зида. У општем случају, он је стављен под контролу истог ЦНИ-ја, због чега се било какве интервенције треће стране у иптаблес могу погрешно протумачити или потпуно занемарити.
И „из кутије“ за организовање управљања мрежним политикама у Кубернетес кластеру је обезбеђено . Овај ресурс, дистрибуиран преко изабраних именских простора, може да садржи правила за разликовање приступа од једне апликације другој. Такође вам омогућава да конфигуришете приступачност између одређених подова, окружења (простора имена) или блокова ИП адреса:
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 врсте саобраћаја: улазак у под (Ингресс) и одлазни из њега (Егресс).
Заправо, политика је подељена у ове 2 категорије на основу правца кретања.
Следећи захтевани атрибут је селектор; онај на кога важи правило. Ово може бити под (или група подова) или окружење (тј. именски простор). Важан детаљ: оба типа ових објеката морају да садрже ознаку (налепница у терминологији Кубернетес) – то су они којима оперишу политичари.
Поред коначног броја селектора уједињених неком врстом ознаке, могуће је писати правила попут „Дозволи/забрани све/свако” у различитим варијацијама. У ту сврху се користе конструкције облика:
podSelector: {}
ingress: []
policyTypes:
- Ingress— у овом примеру, сви подови у окружењу су блокирани од долазног саобраћаја. Супротно понашање се може постићи следећом конструкцијом:
podSelector: {}
ingress:
- {}
policyTypes:
- IngressСлично за одлазне:
podSelector: {}
policyTypes:
- Egress- да га искључим. А ево шта треба укључити:
podSelector: {}
egress:
- {}
policyTypes:
- EgressВраћајући се на избор ЦНИ додатка за кластер, вреди напоменути да не подржава сваки мрежни додатак НетворкПолици. На пример, већ поменути Фланнел не зна како да конфигурише мрежне политике, које у званичном репозиторијуму. Тамо се помиње и алтернатива – пројекат отвореног кода , што значајно проширује стандардни скуп Кубернетес АПИ-ја у смислу мрежних политика.
Упознавање Калико: теорија
Додатак Цалицо се може користити у интеграцији са Фланнел (подпројекат ) или независно, покривајући и мрежно повезивање и могућности управљања доступношћу.
Које могућности пружа коришћење К8с „упакираног“ решења и АПИ сета из Цалицо-а?
Ево шта је уграђено у НетворкПолици:
- политичари су ограничени окружењем;
- политике се примењују на махуне означене етикетама;
- правила се могу применити на подове, окружења или подмреже;
- правила могу да садрже протоколе, именоване или симболичке спецификације портова.
Ево како Цалицо проширује ове функције:
- политике се могу применити на било који објекат: под, контејнер, виртуелну машину или интерфејс;
- правила могу да садрже одређену радњу (забрана, дозвола, евидентирање);
- циљ или извор правила може бити порт, опсег портова, протоколи, ХТТП или ИЦМП атрибути, ИП или подмрежа (4. или 6. генерације), било који селектори (чворови, домаћини, окружења);
- Поред тога, можете регулисати пролаз саобраћаја користећи ДНАТ подешавања и смернице за прослеђивање саобраћаја.
Прва урезивања на ГитХуб-у у Цалицо репозиторијуму датирају из јула 2016. године, а годину дана касније пројекат је заузео водећу позицију у организовању Кубернетес мрежног повезивања - о томе сведоче, на пример, резултати анкете, :
Многа велика управљана решења са К8с, као нпр , , а други су почели да га препоручују за употребу.
Што се тиче перформанси, овде је све одлично. У тестирању свог производа, развојни тим Цалицо је показао астрономске перформансе, покренувши више од 50000 контејнера на 500 физичких чворова са брзином креирања од 20 контејнера у секунди. Нису идентификовани проблеми са скалирањем. Такви резултати већ при најави прве верзије. Независне студије које се фокусирају на проток и потрошњу ресурса такође потврђују да су перформансе Цалицо-а скоро једнако добре као и Фланнел-ове. :
Пројекат се веома брзо развија, подржава рад у популарним решењима којима се управља К8с, ОпенСхифт, ОпенСтацк, могуће је користити Цалицо приликом постављања кластера користећи , постоје референце на изградњу сервисних мрежа ( користи се у спрези са Истио).
Вежбајте са Цалицо
У општем случају коришћења ваниле Кубернетес-а, инсталирање ЦНИ-ја се своди на коришћење датотеке calico.yaml, , с помосьу kubectl apply -f.
По правилу, тренутна верзија додатка је компатибилна са најновијим 2-3 верзије Кубернетеса: рад у старијим верзијама није тестиран и није загарантован. Према речима програмера, Цалицо ради на језгрима Линука изнад 3.10 са ЦентОС 7, Убунту 16 или Дебиан 8, на врху иптаблес-а или ИПВС-а.
Изолација у окружењу
За опште разумевање, погледајмо једноставан случај да бисмо разумели како се мрежне политике у Цалицо нотацији разликују од стандардних и како приступ креирању правила поједностављује њихову читљивост и флексибилност конфигурације:
У кластеру су распоређене 2 веб апликације: у Ноде.јс и ПХП, од којих једна користи Редис. Да бисте блокирали приступ Редис-у из ПХП-а, уз одржавање везе са Ноде.јс, само примените следеће смернице:
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У суштини смо дозволили долазни саобраћај ка Редис порту са Ноде.јс. И очигледно ништа друго нису забранили. Чим се НетворкПолици појави, сви селектори поменути у њој почињу да се изолују, осим ако није другачије назначено. Међутим, правила изолације се не примењују на друге објекте које селектор не покрива.
Пример користи apiVersion Кубернетес из кутије, али ништа вас не спречава да га користите . Синтакса је тамо детаљнија, тако да ћете морати да препишете правило за горњи случај у следећем облику:
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
Горе поменуте конструкције за дозвољавање или одбијање целокупног саобраћаја преко редовног НетворкПолици АПИ-ја садрже конструкције са заградама које је тешко разумети и запамтити. У случају Цалицо, да бисте променили логику правила заштитног зида на супротну, само промените 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А ако користите Цалицо смернице, синтакса ће бити оваква:
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Уопштено говорећи, додавањем оваквих политика за специфичне потребе, можете се заштитити од злонамерног или случајног мешања у рад апликација у кластеру.
Најбоља пракса, према креаторима Цалицо-а, је приступ „Блокирај све и експлицитно отвори шта ти треба“, документован у (други следе сличан приступ - посебно у ).
Коришћење додатних Цалицо објеката
Дозволите ми да вас подсетим да кроз проширени скуп Цалицо АПИ-ја можете регулисати доступност чворова, не ограничавајући се на подове. У следећем примеру користећи GlobalNetworkPolicy могућност прослеђивања ИЦМП захтева у кластеру је затворена (на пример, пингови од модула до чвора, између модула или од чвора до ИП модула):
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
У горњем случају, и даље је могуће да чворови кластера „допру” један до другог преко ИЦМП-а. И ово питање се решава средствима 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"]Случај ВПН
Коначно, даћу веома стваран пример коришћења Цалицо функција за случај интеракције скоро кластера, када стандардни скуп политика није довољан. Да би приступили веб апликацији, клијенти користе ВПН тунел, а овај приступ је строго контролисан и ограничен на одређену листу услуга дозвољених за коришћење:
Клијенти се повезују на ВПН преко стандардног УДП порта 1194 и, када се повежу, примају руте до подмрежа кластера модула и услуга. Читаве подмреже се гурају да не би изгубиле услуге током рестартовања и промене адресе.
Порт у конфигурацији је стандардан, што намеће неке нијансе у процесу конфигурисања апликације и преношења у Кубернетес кластер. На пример, у истом АВС ЛоадБаланцер за УДП се појавио буквално крајем прошле године на ограниченој листи региона, а НодеПорт се не може користити због његовог прослеђивања на свим чворовима кластера и немогуће је скалирати број инстанци сервера за сврхе толеранције грешака. Осим тога, мораћете да промените подразумевани опсег портова...
Као резултат претраживања могућих решења, изабрано је следеће:
- Подови са ВПН-ом су заказани по чвору у
hostNetwork, односно на стварну ИП адресу. - Услуга је постављена напољу кроз
ClusterIP. На чвору је физички инсталиран порт који је доступан споља уз мање резерве (условно присуство праве ИП адресе). - Утврђивање чвора на коме се махуна ружа налази ван оквира наше приче. Само ћу рећи да можете да повежете услугу са чвором или да напишете малу помоћну услугу која ће надгледати тренутну ИП адресу ВПН услуге и уређивати ДНС записе регистроване код клијената - ко има довољно маште.
Из перспективе рутирања, можемо јединствено идентификовати ВПН клијента по његовој ИП адреси коју издаје ВПН сервер. Испод је примитиван пример ограничавања приступа таквог клијента услугама, илустрован на горе поменутом Редис-у:
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, али је истовремено очуван рад ДНС услуге, чије функционисање често пати приликом састављања правила. Јер, као што је раније поменуто, када се појави селектор, подразумевана политика одбијања се примењује на њега осим ако није другачије назначено.
Резултати
Стога, користећи напредни АПИ Цалицо, можете флексибилно да конфигуришете и динамички мењате рутирање унутар и око кластера. Генерално, његова употреба може изгледати као гађање врабаца из топа, а имплементација Л3 мреже са БГП и ИП-ИП тунелима изгледа монструозно у једноставној Кубернетес инсталацији на равној мрежи... Међутим, иначе алат изгледа прилично одржив и користан .
Изоловање кластера да би се испунили безбедносни захтеви можда није увек изводљиво, и ту Цалицо (или слично решење) долази у помоћ. Примери дати у овом чланку (са мањим изменама) се користе у неколико инсталација наших клијената у АВС.
ПС
Прочитајте и на нашем блогу:
- «";
- „Илустровани водич за умрежавање у Кубернетесу“: , ;
- «'.
Извор: ввв.хабр.цом