点赞
评论
收藏
分享
举报
NGINX 服务网格简介
发表于2021-06-22 14:12

浏览 534

NGINX 服务网格 (NSM) 开发版是一个全面集成的轻量级服务网格,利用由 NGINX Plus 提供支持的数据平面管理 Kubernetes 环境中的容器流量。


随着部署规模的扩大和复杂性的提高,组织在采用微服务方法方面面临诸多挑战。由于服务之间的通信错综复杂,故障排除可能会变得更加棘手,并且更多的服务意味着更多的资源需要管理。


NSM 能够帮助您有效解决这些问题,支持您集中配置:


  • 安全性 – 安全的重要性已达到前所未有的高度。数据泄露每年都会给企业造成价值数百万美元的收入和声誉损失。NSM 可确保所有通信均经过 mTLS 加密,有效阻止黑客窃取网络上的敏感数据。访问控制支持您决定哪些服务可以相互通信。
  • 流量管理 – 部署新版应用时,您可能希望从一开始就限制其可接收流量的阈值,以防出现漏洞。借助 NSM 智能容器流量管理,您可以指定一些策略来限制流向新服务的流量,并随着时间的推移逐渐放宽限制。借助速率限制和断路器等功能,您可以完全控制通过服务的流量。
  • 可视化 – 就故障排除和可视化而言,管理数以千计的服务犹如一场噩梦。NSM 内置的 Grafana 仪表盘可通过显示 NGINX Plus 中的全套指标,帮助您走出这一梦魇。此外,Open Tracing 集成还支持精细的事务跟踪。
  • 混合部署 – 如果同大多数企业一样,贵企业的整个基础设施也不在 Kubernetes 中运行,那么 NSM 可帮助您确保传统应用不被落下。借助 NGINX Ingress 控制器集成,传统服务能够与网格服务相互通信。


NSM通过将加密和身份验证无缝应用于容器流量来确保零信任环境中的应用程序安全。它提供对事务的监控和洞察,可帮助组织快速、准确地发现和解决问题。它还提供细粒度的流量控制,支持 DevOps 团队部署和优化应用组件,同时支持 Dev 团队构建并轻松连接分布式应用。



什么是 NGINX 服务网格?

NSM 包含一个面向东西向(服务到服务)流量的统一数据平面,以及对面向南北向流量的 NGINX Plus Ingress 控制器的原生集成功能,两者由单个控制平面进行管理。


控制平面是为NGINX Plus数据平面设计和优化的,并定义了分配给NGINX Plus sidecar的流量管理规则。


借助 NSM,sidecar 代理能够与网格中的每项服务一起部署。sidecar 代理还可以与以下开源解决方案相集成:


  • Grafana – 可实现 Prometheus 指标的可视化;内置的 NSM 仪表盘可帮助您轻松上手
  • Kubernetes Ingress 控制器 – 管理网格的进出流量
  • SPIRE – 证书颁发机构,负责管理、分发和更新网格证书
  • NATS –可扩展的消息传递平面,用于从控制平面向sidecar传递消息,例如路径更新。
  • Open Tracing – 分布式跟踪(同时支持 Zipkin 和 Jaeger)
  • Prometheus – 收集和存储来自 NGINX Plus sidecar 的指标,例如请求数、连接数和 SSL 握手数



特性和组件

NGINX Plus 作为数据平面跨越 sidecar 代理(东西向流量)和 Ingress 控制器(南北向流量),可拦截和管理服务之间的容器流量。特性包括:

  • 双向 TLS (mTLS) 身份验证
  • 负载均衡
  • 高可用性
  • 速率限制
  • 断路
  • 蓝绿部署和金丝雀部署
  • 访问控制



NGINX 服务网格入门

在使用 NSM 之前,您需要:

  • 进入 Kubernetes 环境。NGINX 服务网格适用于多个 Kubernetes 平台,包括 Amazon Elastic Container Service for Kubernetes (EKS)、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE)、VMware vSphere 和独立的裸金属集群。‑‑
  • 在要安装 NSM 的设备上安装 kubectl 命令行程序。
  • 访问 NGINX 服务网格发布包。该发布包不仅包含需要推送到 Kubernetes 集群可访问的私有镜像仓库的 NSM 镜像,而且包含用于部署 NSM 的 nginx-meshctl 二进制文件。


如使用默认设置部署 NSM,需运行以下命令。在部署过程中,会跟踪确认网格组件是否部署成功,并最终确认 NSM 是否在以自己的命名空间中运行:

$ 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

如要验证 NSM 控制平面是否在 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 sidecar代理默认情况下会注入已部署的应用程序中。如欲了解如何禁用自动注入,请查看文档


例如,如果我们将睡眠应用部署在默认的名称空间中,然后检查 Pod,则会看到两个容器正在运行,即睡眠应用和关联的 NGINX Plus sidecar:

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

您还可以通过运行以下命令,向本地机器暴露 sidecar,从而使用 NGINX Plus 本地仪表盘监控睡眠应用:

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

然后在浏览器中导航到 http://localhost:8080/dashboard.html。您还可以连接到 Prometheus 服务器,以监控睡眠应用。



您可以使用 Kubernetes 中的自定义资源来配置流量策略,例如访问控制、速率限制和断路。如欲了解更多信息,请查看文档



已修改于2023-03-08 02:22
本作品系原创
创作不易,留下一份鼓励
NGINX官方账号

暂无个人介绍

关注



写下您的评论
发表评论
全部评论(0)

按点赞数排序

按时间排序

关于作者
NGINX官方账号
这家伙很懒还未留下介绍~
171
文章
21
问答
180
粉丝
相关文章
2019年Nginx发布了6个stable版本以及12个mainline版本,这些发布要么修改了重要的漏洞,要么新增了很有用的特性。如果你不能及时升级Nginx,那么既无法享受到技术进步带来的降本增效,还会让服务暴露在安全风险之下。十多年前,我们大可以升级前在官网上发个公告,声明某个凌晨不提供服务,那时可以从容地停止进程、更换程序、重启服务。然而,当下的用户却很难容忍停机升级这种体验,尤其对于接入层充当负载均衡的Nginx来说,它的并发连接数以百万计,哪怕只终止Nginx进程1秒钟,也会导致大量用户出现业务中断。怎样保证升级高负载的Nginx时,不影响到海量的在线用户呢?而且,虽然官方Nginx是稳定的,但毕竟Nginx在编译期可以定制加入各种C模块,如果某些模块在升级后出现异常,就需要将Nginx回滚到旧版本,此时又怎样保证降级时也不会影响到正常服务的在线用户?实际上,Nginx的热升级功能可以解决上述问题,它允许新老版本灰度地平滑过渡,这受益于Nginx的多进程架构。本文将介绍该如何升级、回滚Nginx,以及Nginx的进程架构是怎样保障不对用户产生影响的。理解热升级后,你也能更透
点赞 12
浏览 3.8k
系统层优化系统socket层优化echo65535>/proc/sys/net/core/somaxconn 准许最大链接数echo1>/proc/sys/net/ipv4/tcp_tw_recycle 快速回收链接echo1>/proc/sys/net/ipv4/tcp_tw_reuse  重用链接echo0>/proc/sys/net/ipv4/tcp_syncookies 关闭洪水抵御系统文件层优化ulimit-n65535nginx配置层优化nginxsocket层优化 worker_connections 10240;nginx层打开文件数优化worker_rlimit_nofile20000;ab-n500000-c20000 http://192.168.1.52/index.htmlServerSoftware:    nginx/1.10.2ServerHostname:    192.168.1.52ServerPort:      80DocumentPath:
点赞 4
浏览 605
nginx-elastic-clientTostructureyourelasticclientcommandinyournginxproxyformultipleelasticsearchserver.TableofContentsIntroductionUsageInstallationTestWhyneedthisSupportCopyright&LicenseIntroductionnginx-elastic-clientisanginxmodulewhichallowtoproxytoelasticserverwithgivenpre-defined/dynamiccommand.Usage0.Setupyourelasticupstream#nginx.conf upstreamelastic_upstream{ server127.0.0.1:9200; }1.Simplecreateindexcommand,pleasenotedthathttp
点赞 0
浏览 541