Мы рады прадставіць папярэднюю версію (NSM), звязаную легкаважную service mesh, якая выкарыстоўвае data plane на аснове NGINX Plus для кіравання трафікам кантэйнераў у асяроддзі Kubernetes.
NSM можна бясплатна . Мы спадзяемся, што вы паспрабуеце яго выкарыстоўваць для dev і test акружэнняў - і чакаем вашых водгукаў .
Укараненне метадалогіі мікрасэрвісаў спалучана з цяжкасцямі пры росце маштабаў паставак, а таксама іх ускладненні. Сувязь паміж сэрвісамі ўскладняецца, праблемы з адладкай робяцца цяжэй, усё больш сервісаў патрабуе больш рэсурсаў для кіравання.
NSM вырашае гэтыя праблемы, падаючы вам у першую чаргу:
- бяспеку, якая зараз важней чым калі-небудзь. Уцечка дадзеных можа каштаваць кампаніі мільёны долараў штогод у выглядзе страт даходаў і рэпутацыі. NSM забяспечвае шыфраванне ўсіх злучэнняў з дапамогай mTLS – так што адчувальных дадзеных, якія могуць выкрасці ўзломшчыкі па сетцы, проста няма. Кантроль доступу дазваляе задаць палітыкі, як сэрвісы будуць мець зносіны з іншымі сэрвісамі.
- Упраўленне трафікам. Пры пастаўцы новай версіі прыкладання вы магчыма захочаце для пачатку абмежаваць яму ўваходзіць трафік на выпадак памылкі. З дапамогай інтэлектуальнага кіравання трафікам кантэйнераў ад NSM вы можаце задаць палітыку абмежавання трафіку новым сэрвісам, якая будзе нарошчваць трафік з цягам часу. Іншыя функцыі, напрыклад абмежаванне хуткасці і circuit breakers, даюць вам поўны доступ да кіравання мінанні трафіку ўсім вашым сэрвісам.
- Візуалізацыя. Кіраванне тысячамі сэрвісаў можа быць кашмарам адладкі і візуалізацыі. NSM дапамагае зладзіцца з такой сітуацыяй з дапамогай убудаванай панэлі кіравання Grafana, на якой адлюстроўваюцца ўсе характарыстыкі, даступныя ў NGINX Plus. А таксама ўкаранёная Open Tracing дазваляе дэталёва сачыць за транзакцыямі.
- Гібрыдныя пастаўкі, калі ваша кампанія, як і большасць іншых, не выкарыстоўвае інфраструктуру, поўнасцю запушчаную на Kubernetes. NSM гарантуе, што старыя прыкладанні не застануцца без нагляду. З дапамогай укаранёнага NGINX Kubernetes Ingress Controller старыя сэрвісы змогуць звязацца з mesh сэрвісамі, і наадварот.
NSM таксама забяспечвае бяспеку прыкладанняў у асяроддзі з нулявым даверам, празрыста ужываючы шыфраванне і аўтэнтыфікацыю трафіку кантэйнераў. Таксама ён дае магчымасць назірання і аналізу транзакцый, дапамагаючы хутка і дакладна запускаць разгортванні і ўстараняць праблемы. Акрамя таго, забяспечваецца дэталёвы кантроль трафіку, дазваляючы камандам DevOps разгортваць і аптымізаваць часткі прыкладанняў, адначасова даючы магчымасць распрацоўнікам ствараць і лёгка злучаць іх размеркаваныя прыкладанні.
Як уладкованы NGINX Service Mesh?
NSM складаецца з аб'яднанага data plane для гарызантальнага (сэрвіс-да-сэрвісу) трафіку і ўкаранёнага NGINX Plus Ingress Controller для вертыкальнага, якія кіруюцца адзіным control plane.
Control plane спецыяльна распрацавана і аптымізавана для NGINX Plus data plane, вызначае правілы кіравання трафікам, размеркаваныя па NGINX Plus sidecars.
У NSM sidecars proxy усталёўваюцца для кожнага сэрвісу ў mesh. Яны ўзаемадзейнічаюць з наступнымі рашэннямі з адкрытым зыходным кодам:
- Grafana, візуалізацыя параметраў Prometheus, убудаваная панэль NSM дапамагае вам пры працы;
- Kubernetes Ingress Controllers, для кіравання ўваходным і выходным трафікам у mesh;
- SPIRE, CA для кіравання, размеркавання і абнаўлення сертыфікатаў у mesh;
- NATS, якая маштабуецца сістэма адпраўкі паведамленняў, напрыклад абнаўленні маршрутаў, з control plane да sidecars;
- Open Tracing, размеркаваная адладка (падтрымліваюцца Zipkin і Jaeger);
- Prometheus, збор і захоўванне характарыстык ад NGINX Plus sidecars, напрыклад лік запытаў, злучэнняў і SSL handshakes.
Функцыі і кампаненты
NGINX Plus у якасці data plane ахоплівае sidecar proxy (гарызантальны трафік) і Ingress controller (вертыкальны), перахапляючы і кіруючы трафікам кантэйнераў паміж сэрвісамі.
Функцыі ўключаюць:
- Узаемную аўтэнтыфікацыю TLS (mTLS);
- Балансаванне нагрузкі;
- адмоваўстойлівасць;
- Абмежаванне хуткасці;
- Circuit breaking;
- Сіне-зялёныя і канарэечныя разгортванні;
- Кантроль доступу.
Запуск NGINX Service Mesh
Для запуску NSM трэба:
- доступ да асяроддзя Kubernetes. NGINX Service Mesh падтрымліваецца на шматлікіх платформах Kubernetes, у тым ліку Amazon Elastic Container Service for Kubernetes (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), VMware vSphere і звычайныя кластара Kubernetes, разгорнутыя на "жалезных" серверах;
- Інструмент
kubectl, усталяваны на машыне, адкуль будзе ўсталёўвацца NSM; - Доступ да пакетаў выпускаў NGINX Service Mesh. У пакеце ёсць выявы NSM, патрэбныя для выгрузкі ў зачыненую registry для кантэйнераў, даступную ў кластары Kubernetes. Пакет таксама змяшчае
nginx-meshctl, патрэбную для разгортвання NSM.
Для таго, каб разгарнуць NSM з наладамі па змаўчанні, запусціце наступную каманду. Падчас разгортвання выводзяцца паведамленні аб паспяховай усталёўцы кампанентаў і, нарэшце, паведамленне аб тым, што NSM працуе ў асобнай прасторы імёнаў (для пачатку трэба яго і змясціць у registry, заўв. перакладчыка):
$ DOCKER_REGISTRY=your-Docker-registry ; MESH_VER=0.6.0 ;
./nginx-meshctl deploy
--nginx-mesh-api-image "${DOCKER_REGISTRY}/nginx-mesh-api:${MESH_VER}"
--nginx-mesh-sidecar-image "${DOCKER_REGISTRY}/nginx-mesh-sidecar:${MESH_VER}"
--nginx-mesh-init-image "${DOCKER_REGISTRY}/nginx-mesh-init:${MESH_VER}"
--nginx-mesh-metrics-image "${DOCKER_REGISTRY}/nginx-mesh-metrics:${MESH_VER}"
Created namespace "nginx-mesh".
Created SpiffeID CRD.
Waiting for Spire pods to be running...done.
Deployed Spire.
Deployed NATS server.
Created traffic policy CRDs.
Deployed Mesh API.
Deployed Metrics API Server.
Deployed Prometheus Server nginx-mesh/prometheus-server.
Deployed Grafana nginx-mesh/grafana.
Deployed tracing server nginx-mesh/zipkin.
All resources created. Testing the connection to the Service Mesh API Server...
Connected to the NGINX Service Mesh API successfully.
NGINX Service Mesh is running.Для атрымання дадатковых параметраў, уключаючы пашыраныя наладкі, запусціце гэтую каманду:
$ nginx-meshctl deploy –hПраверыць, што control plane працуе карэктна ў прасторы імёнаў nginx-mesh, можна так:
$ kubectl get pods –n nginx-mesh
NAME READY STATUS RESTARTS AGE
grafana-6cc6958cd9-dccj6 1/1 Running 0 2d19h
mesh-api-6b95576c46-8npkb 1/1 Running 0 2d19h
nats-server-6d5c57f894-225qn 1/1 Running 0 2d19h
prometheus-server-65c95b788b-zkt95 1/1 Running 0 2d19h
smi-metrics-5986dfb8d5-q6gfj 1/1 Running 0 2d19h
spire-agent-5cf87 1/1 Running 0 2d19h
spire-agent-rr2tt 1/1 Running 0 2d19h
spire-agent-vwjbv 1/1 Running 0 2d19h
spire-server-0 2/2 Running 0 2d19h
zipkin-6f7cbf5467-ns6wc 1/1 Running 0 2d19hУ залежнасці ад параметраў разгортвання, якія ўстанаўліваюць палітыкі ручнога або аўтаматычнага інжэктавання, проксі NGINX sidecars будуць дадавацца да прыкладанняў па змаўчанні. Для адключэння аўтаматычнага дадання чытайце
Напрыклад калі мы разгорнем прыкладанне спаць у прасторы імёнаў дэфолт, а затым праверым Pod - убачым два запушчаных кантэйнера, прыкладанне спаць і звязаны з ім sidecar:
$ kubectl apply –f sleep.yaml
$ kubectl get pods –n default
NAME READY STATUS RESTARTS AGE
sleep-674f75ff4d-gxjf2 2/2 Running 0 5h23mТаксама мы можам сачыць за дадаткам спаць у панэлі NGINX Plus, запускаючы гэтую каманду для атрымання доступу да sidecar з вашай лакальнай машыны:
$ kubectl port-forward sleep-674f75ff4d-gxjf2 8080:8886Затым проста заходзім у браўзэры. Вы таксама можаце злучыцца з Prometheus каб сачыць за дадаткам спаць.
Вы можаце выкарыстоўваць асобныя рэсурсы Kubernetes для налады палітык трафіку, напрыклад кантролю доступу, абмежаванні хуткасці і circuit breaking, для гэтага глядзіце
Заключэнне
NGINX Service Mesh бясплатна даступная для загрузкі на . Паспрабуйце яе ў працы на вашых dev і test асяродках і .
Каб паспрабаваць NGINX Plus Ingress Controller, актывуйце на 30 дзён, або для абмеркавання вашых варыянтаў выкарыстання.
Пераклад у аўтарстве Паўла Дзямковіча, інжынера кампаніі . Сістэмнае адміністраванне за 15 000 ₽ у месяц. І як асобнае падраздзяленне - навучальны цэнтр , практыка і нічога, акрамя практыкі.
Крыніца: habr.com