Magamit ang NGINX Service Mesh

Magamit ang NGINX Service Mesh

Nalipay kami sa pagpresentar sa usa ka preview nga bersyon NGINX Service Mesh (NSM), usa ka bundle nga lightweight service mesh nga naggamit ug NGINX Plus-based data plane aron pagdumala sa container traffic sa Kubernetes environment.

Libre ang NSM download dinhi. Kami nanghinaut nga imong sulayan kini alang sa dev ug pagsulay nga mga palibot - ug magpaabut sa imong feedback sa GitHub.

Ang pagpatuman sa microservices methodology puno sa mga kalisud samtang ang gidak-on sa paghatud motubo, ingon man ang pagkakomplikado niini. Ang komunikasyon tali sa mga serbisyo nahimong mas komplikado, ang mga problema sa pag-debug nahimong mas lisud, ug nagkadaghan ang mga serbisyo nga nagkinahanglan og dugang nga mga kapanguhaan aron madumala.

Gisulbad sa NSM kini nga mga problema pinaagi sa paghatag kanimo sa:

  • Kasegurohan, nga mas importante karon kay sa kaniadto. Ang paglapas sa datos mahimong mogasto sa usa ka kompanya og minilyon ka dolyar kada tuig sa nawala nga kita ug reputasyon. Gisiguro sa NSM nga ang tanan nga koneksyon gi-encrypt gamit ang mTLS, busa wala’y sensitibo nga datos nga mahimong kawaton sa mga hacker sa network. Ang kontrol sa pag-access nagtugot kanimo sa pagtakda sa mga palisiya kung giunsa ang komunikasyon sa mga serbisyo sa ubang mga serbisyo.
  • pagdumala sa trapiko. Kung nagpadala ug bag-ong bersyon sa usa ka aplikasyon, mahimo nimong sugdan pinaagi sa pagpugong sa umaabot nga trapiko niini kung adunay sayup. Uban sa intelihenteng pagdumala sa trapiko sa sudlanan sa NSM, mahimo nimong itakda ang usa ka palisiya sa pagpugong sa trapiko alang sa mga bag-ong serbisyo nga makapadugang sa trapiko sa paglabay sa panahon. Ang ubang mga feature, sama sa speed limiting ug circuit breakers, naghatag kanimo og bug-os nga kontrol sa dagan sa trapiko sa tanan nimong mga serbisyo.
  • Paglaraw. Ang pagdumala sa libu-libo nga mga serbisyo mahimong usa ka pag-debug ug paghanduraw nga damgo. Ang NSM nagtabang sa pag-atubang niini nga sitwasyon gamit ang built-in nga Grafana dashboard nga nagpakita sa tanang feature nga anaa sa NGINX Plus. Ug usab ang gipatuman nga Open Tracing nagtugot kanimo sa pagmonitor sa mga transaksyon sa detalye.
  • Hybrid nga paghatud, kung ang imong kompanya, sama sa kadaghanan, wala mogamit sa imprastraktura nga nagdagan sa Kubernetes. Gisiguro sa NSM nga ang mga aplikasyon sa kabilin dili pasagdan nga wala maatiman. Sa tabang sa gipatuman nga NGINX Kubernetes Ingress Controller, ang mga serbisyo sa kabilin makahimo sa pagpakigsulti sa mga serbisyo sa mesh, ug vice versa.

Gisiguro usab sa NSM ang seguridad sa aplikasyon sa mga zero trust environment pinaagi sa klaro nga paggamit sa encryption ug authentication sa container traffic. Naghatag usab kini og visibility sa transaksyon ug pagtuki, nga nagtabang kanimo sa madali ug tukma nga paglansad sa mga deployment ug pagsulbad sa mga problema. Naghatag usab kini og granular nga pagkontrol sa trapiko, nga gitugotan ang mga koponan sa DevOps sa pag-deploy ug pag-optimize sa mga bahin sa mga aplikasyon samtang gitugotan ang mga developer nga magtukod ug dali nga makonekta ang ilang gipang-apod-apod nga mga aplikasyon.

Giunsa pagtrabaho ang NGINX Service Mesh?

Ang NSM naglangkob sa usa ka hiniusang data plane para sa horizontal (service-to-service) nga trapiko ug usa ka embedded NGINX Plus Ingress Controller para sa vertical nga trapiko, nga gidumala sa usa ka control plane.

Ang kontrol nga eroplano espesipikong gidesinyo ug gi-optimize alang sa NGINX Plus data plane ug naghubit sa mga lagda sa pagkontrol sa trapiko nga gipang-apod-apod sa mga sidecar sa NGINX Plus.

Sa NSM, gi-install ang mga sidecar proxy alang sa matag serbisyo sa mesh. Nag-interface sila sa mosunod nga open source nga mga solusyon:

  • Grafana, Prometheus parameter visualization, built-in NSM panel makatabang kanimo sa imong trabaho;
  • Kubernetes Ingress Controllers, alang sa pagdumala sa umaabot ug paggawas nga trapiko sa mesh;
  • SPIRE, CA alang sa pagdumala, pag-apod-apod ug pag-update sa mga sertipiko sa mesh;
  • NATS, usa ka scalable nga sistema sa pagpadala sa mga mensahe, sama sa mga update sa ruta, gikan sa control plane ngadto sa sidecars;
  • Bukas nga Pagsubay, gipang-apod-apod nga pag-debug (gisuportahan ang Zipkin ug Jaeger);
  • Ang Prometheus, nagkolekta ug nagtipig sa mga kinaiya gikan sa NGINX Plus sidecars, sama sa gidaghanon sa mga hangyo, koneksyon ug SSL handshakes.

Mga gimbuhaton ug mga sangkap

Ang NGINX Plus isip data plane naglangkob sa sidecar proxy (horizontal traffic) ug Ingress controller (vertical), intercepting ug pagdumala sa container traffic tali sa mga serbisyo.

Ang mga bahin naglakip sa:

  • Mutual TLS (mTLS) authentication;
  • Pagbalanse sa load;
  • Ang pagtugot sa sayup;
  • Limitasyon sa tulin;
  • Pagputol sa circuit;
  • Asul-berde ug pag-deploy sa canary;
  • Pagkontrol sa pag-access.

Paglansad sa NGINX Service Mesh

Aron makadagan ang NSM kinahanglan nimo:

  • access sa Kubernetes environment. Ang NGINX Service Mesh gisuportahan sa daghang mga platform sa Kubernetes, lakip ang Amazon Elastic Container Service para sa Kubernetes (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), VMware vSphere, ug regular nga Kubernetes clusters nga gi-deploy sa mga hardware server;
  • Galamiton kubectl, na-install sa makina diin i-install ang NSM;
  • Pag-access sa NGINX Service Mesh nga mga pakete sa pagpagawas. Ang package adunay mga imahe sa NSM nga gikinahanglan alang sa pag-upload sa usa ka pribado nga rehistro alang sa mga sudlanan nga magamit sa cluster sa Kubernetes. Ang pakete adunay usab nginx-meshctl, gikinahanglan sa pag-deploy sa NSM.

Aron i-deploy ang NSM nga adunay mga default setting, padagana ang mosunod nga sugo. Atol sa pag-deploy, ang mga mensahe gipakita nga nagpaila sa malampuson nga pag-instalar sa mga sangkap ug, sa katapusan, usa ka mensahe nga nagpakita nga ang NSM nagdagan sa usa ka lahi nga namespace (kinahanglan nimo nga una ΡΠΊΠ°Ρ‡Π°Ρ‚ΡŒ ug ibutang kini sa rehistro, gibanabana. tighubad):

$ 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.

Alang sa dugang nga mga kapilian, lakip ang mga advanced setting, padagana kini nga mando:

$ nginx-meshctl deploy –h

Susiha nga ang control plane nagtrabaho sa husto sa namespace nginx-mesh, mahimo nimo kini:

$ 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

Depende sa mga setting sa pag-deploy nga nagtakda sa manual o awtomatik nga mga palisiya sa pag-injection, ang NGINX sidecars nga mga proxy idugang sa mga aplikasyon pinaagi sa default. Aron ma-disable ang awtomatikong pagdugang, basaha dinhi

Pananglitan, kung atong i-deploy ang aplikasyon pagkatulog sa namespace Default, ug unya susiha ang Pod - atong makita ang duha ka nagdagan nga mga sudlanan, ang aplikasyon pagkatulog ug ang kaubang sidecar:

$ kubectl apply –f sleep.yaml
$ kubectl get pods –n default
NAME                     READY   STATUS    RESTARTS   AGE
sleep-674f75ff4d-gxjf2   2/2     Running   0          5h23m

Mahimo usab namon nga bantayan ang aplikasyon pagkatulog sa NGINX Plus panel, nga nagpadagan niini nga command aron ma-access ang sidecar gikan sa imong lokal nga makina:

$ kubectl port-forward sleep-674f75ff4d-gxjf2 8080:8886

Unya mosulod na lang mi dinhi sa browser. Mahimo ka usab makonektar sa Prometheus aron ma-monitor ang aplikasyon pagkatulog.

Mahimo nimong gamiton ang indibidwal nga mga kapanguhaan sa Kubernetes aron ma-configure ang mga polisiya sa trapiko, sama sa kontrol sa pag-access, paglimite sa rate ug pagsira sa sirkito, para niini tan-awa. dokumentasyon

konklusyon

Ang NGINX Service Mesh magamit alang sa libre nga pag-download sa portal F5. Sulayi kini sa imong dev ug pagsulay nga mga palibot ug pagsulat kanamo bahin sa mga resulta.

Aron sulayan ang NGINX Plus Ingress Controller, i-aktibo libre nga panahon sa pagsulay sulod sa 30 ka adlaw, o Kontaka kami aron hisgutan ang imong mga kaso sa paggamit.

Hubad ni Pavel Demkovich, inhenyero sa kompanya habagatan nga taytayan. Pagdumala sa sistema alang sa RUB 15 matag bulan. Ug ingon nga usa ka bulag nga dibisyon - usa ka sentro sa pagbansay Slurm, praktis ug walay lain gawas sa praktis.

Source: www.habr.com

Idugang sa usa ka comment