五、DestinationRule 1. 概念字段名称说明spec.host关联 DestinationRule 配置的服务名称，可以是自动发现的服务（例如Kubernetes service name），或通过 ServiceEntry 声明的 hosts。如填写的服务名无法在上述源中找到。则该 DestinationRule 中定义的规则无效spec.subsets定义服务的版本（subsets），版本可通过标签键值对匹配服务中的endpoints。可以在 subsets 级覆盖流量策略配置spec.trafficPolicy定义流量策略，包括负载均衡、连接池、健康检查、TLS 策略等spec.spec.trafficPolicy.loadBalancer配置负载均衡算法，可配置：简单负载均衡算法(round robin，least conn，random...) ，一致性哈希（会话保持，支持按 header name，cookie，IP，query parameter 哈希)，地域感知负载均衡算法spec.trafficPolicy.connectionPool配置与上游服务的连接量，可设置 TCP/HTTP 连接池spec.trafficPolicy.outlierDetection配置从负载均衡池中驱逐不健康的 hostsspec.trafficPolicy.tls连接上游服务的 client 端 TLS 相关配置，与 PeerAuthentication 策略（server 端 TLS 模式配置）配合使用spec.trafficPolicy.portLevelSettings配置端口级的流量策略，该策略会覆盖服务 / subsets 级别的流量策略配置DestinationRule 在路由发生后应用于流量，支持如下配置：负载均衡连接池局部异常点检测客户端 TLS 配置端口流量策略2. 负载均衡设置通过负载均衡设置，可以控制目的地使用的负载均衡算法apiVersion: netweorking.istio.io/v1alpha3 kind: DestinationRule metadata: name: nginx-destination spec: host: nginx.test.svc.cluster.local trafficPolicy: loadBalancer: simple: ROUND_ROBIN # 轮询 subsets: - name: v1 labels: version: vl - name: v2 labels: version: v2simple字段：ROUND_ROBIN：轮询算法，如果未指定则默认采用这种算法LEAST_CONN：最少连接算法，从两个随机选择的服务选择一个活动请求数较少的后端实例RANDOM：从可用的健康实例中随机选择一个PASSTHROUGH：直接转发连接到客户端连接的目标地址，即不做做负载均衡consistentHash 字段：httpHeaderName：基于 HeaderhttpCookie：基于 CookieuseSourcelp：基于源 IP 计算哈希值minimumRingSize：哈希环上虚拟节点数的最小值，节点数越多则负载均衡越精细trafficPolicy: loadBalancer: consistentHash: httpCokkie: name: location ttl: 2s3. 连接池配置可以在 TCP 和 HTTP 层面应用于上游服务的每个主机，可以用它们来控制连接量tcp 连接池配置：maxConnections：上游服务的所有实例建立的最大连接数，默认值1024，属于 TCP 层的配置，对于HTTP，只作用于 HTTP/1.1，因为 HTTP/2 对每个主机都使用单个连接connectTimeout：TCP 连接超时，表示主机网络连接超时，可以改善因调用服务变慢而导致整个链路变慢的情况tcpKeepalive：lstio1.1 版本开始新支持的配置，定期给对端发送一个 keepalive 探测包，判断连接是否可用spec: host: nginx.test.svc.cluster.local trafficPolicy: connectionPool: tcp: maxConnections: 50 connectTimeout: 25ms tcpKeepalive: probes: 5 time: 3600 interval: 60shttp 连接池配置：http1MaxPendingRequests：最大等待 HTTP 请求数，默认值1024，只适用于 HTTP/1.1 的服务，因为 HTTP/2 协议的请求在到来时会立即复用连接，不会在连接池等待http2MaxRequests：最大请求数，默认值1024，只适用于 HTTP/2 服务，因为 HTTP/1.1 使用最大连接数 maxConnections 即可，表示上游服务的所有实例处理的最大请求数maxRequestsPerConnection：每个连接的最大请求数，HTTP/1.1 和 HTTP/2 连接池都遵循此参数，如果没有设置，则代表不限制设置为1时表示每个连接只处理一个请求，相当于禁用了 Keep-alivemaxRetries：最大重试次数，默认值3，表示服务可以执行的最大重试次数。如果调用端因为偶发的抖动导致请求直接失败，则可能会带来业务损失，一般建议配置重试，若重试成功则可正常返回数据，只不过比原来响应得慢一点，但如果重试次数太多，会对性能造成一定的影响idleTimeout：空闲超时，即：在多长时间内没有活动请求则关闭连接# 配置最大80个连接，最多100个并发请求，每个请求的连接数不超过10个，超时时间为30ms spec: host: nginx.test.cluster.local trafficPolicy: connectionPool: tcp: maxConnections: 80 connectTimeout: 30ms http: http2MaxRequests: 100 maxRequestsPerConnection: 104. 异常点检测异常点检测是一个断路器的实现，它跟踪上游服务中每个主机（Pod）的状态，如果其中一个主机开始返回 5xx HTTP 错误，它就会在预定的时间内被从负载均衡池中弹出，对于 TCP 服务，Envoy 将连接超时或失败计算为错误。两种健康检查：主动检查：定期探测目标服务实例，根据应答来判断服务实例的健康状态，如负载均衡器中的健康检查被动检查：通过实际的访问情况来找出不健康的实例，如 Istio 中的异常点检查异常实例检查相关的配置：consecutiveErrors：实例被驱逐前的连续错误次数，默认值5。对于 HTTP 服务，返回502、503 和 504 的请求会被认为异常；对于 TCP 服务，连接超时或者连接错误事件会被认为异常interval：驱逐的时间间隔，默认值10秒，要求大于1毫秒，单位可以是时、分、毫秒baseEjectionTime：最小驱逐时间，一个实例被驱逐的时间等于这个最小驱逐时间乘以驱逐的次数，这样一个因多次异常被驱逐的实例，被驱逐的时间会越来越长，默认值30秒，要求大于1毫秒，单位可以是时、分、毫秒maxEjectionPercent：指负载均衡池中可以被驱逐的故障实例的最大比例，默认值10%，该设置是为了避免太多的服务实例被驱逐导致服务整体能力下降minHealthPercent：最小健康实例比例，是 lstio 1.1 新增的配置，当负载均衡池中的健康实例数的比例大于这个比例时，异常点检查机制可用，反之该功能将被禁用；所有服务实例不管被认定为健康还是不健康，都可以接收请求，参数的默认值为50%# 最大500个http2请求，每个连接不超过10个请求，每5分钟扫描一次上游主机（Pod），如果其中任何一个主机连续失败10次，Envoy 会将其弹出10分钟 trafficPolicy: coninectionPool: http: http2MaxRequests: 500 maxRequestsPerConnection: 10 outlierDetection: consecutiveErrors: 10 interval: 5m baseEjectionTime: 1om5. TLS 设置其包含任何与上游服务连接的 TLS 相关设置trafficPolicy: tls: mode: MUTUAL clientCertificate: ./certs/cert.pem privatekey: ./certs/key - pem caCertificates: ./certs/ca.pemmTLS：双向认证，客户端和服务端都通过证书颁发机构验证彼此的身份，即：由同一个 root ca 生成两套证书，客户端、服务端各一个，客户端通过 https 访问服务时，双方会交换证书，并进行认证，认证通过后即可进行通信TLS 模式：DISABLE：无 TLS 连接SIMPLE：在上游端点发起 TLS 连接ISTIO_MUTUAL：与 MUTUAL 类似，使用 Istio 的 mTLS 证书6. 端口流量策略在端口上配置流量策略，配置后其会覆盖全局的流量策略trafficPolicy: connectionPool: tcp: maxConnections: 80 portLevelSettings: - port: number: 80 loadBalancer: simple: LEAST_CONN connectionPool: tcp: maxConnections: 100 - port: number: 80 loadBalancer: simple: ROUND_ROBIN7. 服务子集subset：定义服务的子集name：服务子集的名称，必填字段，VirtualService 通过该属性引用label：标签，通过一组标签定义属于这个服务子集的实例，如：version（版本）trafficPolicy：应用到该子集上的流量策略# 给名称为 nginx-v1 的服务子集配置最大连接数 spec: hosts: nginx subsets: - name: nginx-v1 labels: version: v2 trafficPolicy: connectionPool: tcp: maxConnections: 100

五、流量管理 - VirtualService 通过 VirtualService，可以定义流量路由规则字段名说明spec.hosts定义路由规则关联一组的hosts，可以是带有通配符的DNS名称或者IP地址（IP地址仅能应用于来源流量为边缘代理网关）。该字段能应用于 HTTP 和 TCP 流量。在 Kubernetes 环境中，可以使用 service 的名称作为缩写，lstio 会按照 VirtualService 所在 namespace 补齐缩写，例如在 default namespace 的 VirtualService 包含 host 缩写 reviews 会被补齐为 reviews.default.svc.cluster.local，为避免误配置，推荐填写 host 全称。spec.gateway定义应用路由规则的来源流量，可以是一个或多个网关，或网格内部的 sidecar，指定方式为[gateway namespace]/[gateway name]，保留字段 mesh 表示网格内部所有的 sidecar，当该参数缺省时,会默认填写 mesh，即该路由规则的来源流量为网格内部所有的 sidecar。spec.http定义一组有序的（优先匹配靠前的路由规则）应用于 HTTP 流量的路由规则，HTTP 路由规则会应用于网格内部的 service 端口命名为http-， http2-，grpc- 开头的流量以及来自 gateway 的协议为 HTTP，HTTP2，GRPC，TLS-Terminated-HTTPS 的流量。spec.http.match定义路由的匹配规则列表，单个匹配规则项内所有条件是且关系，多个匹配规则之间为或关系。spec.http.route定义路由转发目的地列表，一条 HTTP 路由可以是重定向或转发（默认)，转发的目的地可以是一个或多个服务（服务版本），同时也可以配置权重、header 操作等行为。spec.http.redirect定义路由重定向，一条 HTTP 路由可以是重定向或转发（默认），如规则中指定了 passthrough 选项，route.redirect 均会被忽略，可将 HTTP 301重定向到另外的 URL 或Authority。spec.http.rewrite定义重写HTTP URL 或 Authority headers，不能与重定向同时配置，重写操作会在转发前执行。spec.http.timeout请求超时时间spec.http.retries请求重试次数spec.http.fault故障注入策略，开启时超时和重试策略不生效spec.http.mirror定义将 HTTP 流量复制到另一个指定的目的端，被复制的流量按照“best effort”原则，sidecar / 网关不会等待复制流量的响应结果就会从源目的端返回响应。spec.http.mirrorPercent定义镜像流量的复制百分比，默认值为100，即100%spec.http.corsPolicy定义 CORS 策略spec.http.headers定义 header 操作规则，包括 request 和 response header 的增删改。spec.tcp定义一组有序的（优先匹配靠前的路由规则）应用于 TCP 流量的路由规则，该规则会应用于任何非 HTTP 和 TLS 的端口。spec.tcp.match定义路由的匹配规则列表，单个匹配规则项内所有条件是且关系，多个匹配规则之间为或关系。spec.tcp.route定义 TCP 连接转发的目的端。spec.tls定义一组有序的（优先匹配靠前的路由规则）应用于未终止的 TLS 或 HTTPS 流量的路由规则，该路由规则会应用于网格内部的 service 端口命名为 https-，tls- 开头的流量，来自 gateway 的端口协议为 HTTPS，TLS 的未终止加密流量，ServiceEntry 使用 HTTPS，TLS 协议的端口，当 https-，tls- 端口未关联 VirtualService 规则时将会被视为 TCP 流量。spec.tls.match定义 TLS 流量路由的匹配规则列表，单个匹配规则项内所有条件是且关系，多个匹配规则之间为或关系。spec.tls.route定义连接转发的目的端2.1 routeHTTP Route 规则的功能：满足 HTTPMatchRequest 条件的流量都会被路由到 HTTPRouteDestination，执行重定向（HTTPRedirect）、重写（HTTPRewrite）、重试（HTTPRetry）、故障注入（HTTPFaultInjection）、跨站（CorsPolicy）等策略。2.2 matchmatch 是路由的匹配规则，支持 uri、scheme、method、authority 等字段，且支持 perfix（前缀）、exact（精确）、regex（正则）三种匹配模式：# 匹配 uri 以 test 开头的请求 - match: - uri: prefix: "/test"# 匹配 header 中 key 为 source，value 为 abc 的请求 - match: - headers: source: exact: abc# 根据来源标签匹配 - match: sourceLabels: app: nginx version: v1# 匹配 header 中 key 为 source，value 为 test1 的请求 或 uri 以 test2 开头的请求 - match: - headers: source: exact: abc uri: prefix: "/test1" - uri: prefix: "/test2"2.3 路由目标（RouteDestionation）在 HTTPRouteDestionation 中主要包含三个字段：destination（请求目标）、weight（权重）、headers（请求头），其中 destination 必填。destination：通过 host、subset 和 port 三个属性描述，表示最终将流量路由到此目标。host 是 Destination 必选字段，表示在 lstio 中注册的服务名（建议写全域名），subset 表示在 host 上定义的一个子集，如：在灰度发布中将版本定义为 subset，配置路由策略会将流量转发到不同版本的 subset 上。spec: hosts: - test.com http: - route: - destination: host: test.com subset: v1 destination: host: test.com subset : v2weight：表示流量分配的比例，在一个 route 下多个 destination 的 weight 总和要求是100（默认100，必填字段）。如：从原有的 v1 版本中切分 20% 的流量到 v2 版本，这也是灰度发布常用的一个流量策略，即不区分内容，平等的从总流量中切出一部分流量给新版本。spec: hosts: - test.com http: - route: - destination: host: test.com subset: v1 weight: 80 destination: host: test.com subset : v2 weight: 20headers：提供了对 HTTP header 的一种操作机制，可以修改一次 HTTP 请求中的Request 或 Response 的值，包含 request 和 response 两个字段。request：表示在发请求给目标地址时修改 Request 的 headerresponse：表示在返回应答时修改 Response 的 header对应的类型都是 HeaderOperations 类型，使用set、add、remove字段来定义对 Header 的操作set：使用map上的key和value覆盖 Request 和 Response 中对应的 Headeradd：追加map上的key和value到原有的 Headerremove：删除在列表中指定的 Header2.4 HTTP重定向（HTTPRedirect）HTTPRedirect 包含两个字段来表示重定向的目标：uri：替换 URL 中的 uri 部分authority：替换 URL 中的 authority 部分# 对 nginx 服务中，所有前缀为 test1 的请求都会被重定向到 new-test 的 /test/a1 地址 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: nginx namespace: test spec: hosts: - test.com http: - match: - uri: prefix: /test1 redirect: uri: /test/a1 authority: new-test.com2.5 HTTP重写（HTTPRewrite）通过 HTTP 重写可以在将请求转发给目标服务前修改 HTTP 请求中指定部分的内容，HTTP 重写对用户是不可见的（在服务端执行）HTTPRewrite 包含两个字段：uri：重写 URL 中的 uri 部分authority：重写 URL 中的 authority 部分和 HTTPRedirect 规则稍有不同的是，HTTPRedirect 的 uri 只能替换全部的 path，但 HTTPRewrite 的 uri 是可以重写前缀的，即匹配条件是前缀匹配，则只修改匹配到的前缀。# 将请求前缀中的 /test1 重写为 /test/a1 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: nginx namespace: test spec: hosts: - test.com http: - match: - uri: prefix: /test1 rewrite: uri: /test/a1 route: - destination: host: new-test2.6 HTTP重试（HTTPRetry）HTTPRetry 可以定义请求失败时的重试策略，包含三个字段：attempts：必选字段，定义重试的次数perTryTimeout：每次重试超时的时间，单位可以是 ms、s、m和hretryOn：进行重试的条件，多个条件时以逗号分隔5xx：在上游服务返回 5xx 应答码，或者在没有返回时重试gateway-error：类似于5xx异常，只对502、503和504应答码进行重试connect-failure：在链接上游服务失败时重试retriable-4xx：在上游服务返回可重试的4xx应答码时执行重试refused-stream：在上游服务使用 REFUSED_STREAM 错误码重置时执行重试cancelled：gRPC 应答的 Header 中状态码是 cancelled 时执行重试deadline-exceeded：在 gRPC 应答的 Header 中状态码是 deadline-exceeded 时执行重试internal：在 gRPC 应答的 Header 中状态码是 internal 时执行重试resource-exhausted：在 gRPC 应答的 Header 中状态码是 resource-exhausted 时执行重试unavailable：在 gRPC 应答的 Header 中状态码是 unavailable 时执行重试apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: nginx namespace: test spec: hosts: - test.com http: - route: - destination: host: test.com retries: attempts: 3 perTryTimeout: 5s retryOn: 5xx,connect-failure2.7 HTTP流量镜像（HTTPMirror）HTTP 流量镜像指的是将流量转发到原目标地址的同时将流量给另外一个目标地址镜像一份。把生产环境中的实际流量镜像一份到另外一个系统上，完全不会对生产系统产生影响，这里只是镜像了一份流量，数据面代理只需要关注原来转发的流量就可以，不用等待镜像目标地址的返回。apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: nginx namespace: test spec: hosts: - test.com http: - route: - destination: host: test.com subset: v1 mirror: host: test.net subset: v22.8 HTTP故障注入（HTTPFaultInjection）HTTPFaultInjection 通过 delay 和 abort 设置延时和中止两种故障，分别表示 Proxy 延迟转发和终止 HTTP 请求。delay 包含以下两个字段：fixedDelay：必选，表示延迟时间，单位可以是毫秒，秒，分钟和小时，要求至少要大于1毫秒percentage：延时作用在多少比例的请求上# 让 1.5% 的请求延时 5s apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: nginx namespace: test spec: hosts: - test.com http: - route: - destination: host: test.com subset: v1 fault: delay: fixedDelay: 5s percentage: value: 1.5abort 包含以下两个字段：httpStatus：必选，http 状态码percentage：终止故障作用在多少比例的请求上# 让 1.5% 的请求返回 500 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: nginx namespace: test spec: hosts: - test.com http: - route: - destination: host: test.com subset: v1 fault: abort: httpStatus: 500 percentage: value: 1.52.9 HTTP跨域资源共享（CorsPolicy）在 VirtualService 中可以对满足条件的请求配置跨域资源共享，allowOrigin，allowMethods，allowHeader，exposeHeader，maxAge，allowCredentials，等都被转化为 Access-Control-* 的 Header。# 允许来自 new-test.com 的 GET 请求 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: nginx namespace: test spec: hosts: - test.com http: - route: - destination: host: test.com subset: v1 corsPolicy: allowOrigin: - new-test.com allowMethod: - GET maxAge: 2d

四、流量管理 - Gateway 在安装 istio 的时候，同时安装了入口和出口网关，这两个网关都运行了一个 Envoy 代理实例，它们在网格的边缘作为负载均衡器的角色。gateway 资源实例：apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: gateway-demo namespace: default spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - dev.example.com - test.example.com 上述示例做了哪些事：配置了一个代理，作为负载均衡器服务端口为80应用于 istio 入口网关代理hosts 字段作为过滤器，只有以 dev.example.com 和 test.example.com 为目的地的流量才允许通过为了控制和转发流量到集群内运行的实际实例，还需要配置 VirtualService，并与网关相连接。（1）简单路由实例部署 nginx，并通过 istio 网关进行访问--- apiVersion: apps/v1 kind: Deployment metadata: namespace: test name: nginx labels: app: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: restartPolicy: Always containers: - image: 'nginx:latest' imagePullPolicy: IfNotPresent name: nginx env: - name: TZ value: Asia/Shanghai ports: - containerPort: 80 protocol: TCP --- apiVersion: v1 kind: Service metadata: namespace: test name: nginx labels: app: nginx spec: ports: - port: 80 targetPort: 80 protocol: TCP selector: app: nginx# 网关 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: gateway-nginx namespace: test spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - '*'在未绑定 VirtualService 之前，网关还不知道要将流量路由到哪apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: virtualService-nginx namespace: test spec: hosts: - '*' gateways: - gateway-nginx http: - route: - destination: host: nginx.test.svc.cluster.local port: 80部署完之后，通过 curl -v x.x.x.x 即可测试

三、安装 以 istioctl 为例# 下载 curl -L https://istio.io/downloadIstio | sh - cd istio-1.28.1 export PATH=$PWD/bin:$PATH安装目录包含：samples/ 目录下的示例应用bin/ 目录下的 istioctl 客户端可执行文件。# 安装 istioctl install --set profile=demo -y |\ | \ | \ | \ /|| \ / || \ / || \ / || \ / || \ / || \ /______||__________\ ____________________ \__ _____/ \_____/ √ Istio core installed √ Istiod installed √ Ingress gateways installed √ Egress gateways installed √ Installation complete istio 提供的几种内置配置，这些配置文件提供了对 Istio 控制平面和 Istio 数据平面 Sidecar 的定制内容:default：根据 IstioOperator API 的默认设置启动组件。 建议用于生产部署和 Multicluster Mesh 中的 Primary Cluster。您可以运行 istioctl profile dump 命令来查看默认设置。demo：这一配置具有适度的资源需求，旨在展示 Istio 的功能。 它适合运行 Bookinfo 应用程序和相关任务。 此配置文件启用了高级别的追踪和访问日志，因此不适合进行性能测试。minimal：与默认配置文件相同，但只安装了控制平面组件， 它允许您使用 Separate Profile 配置控制平面和数据平面组件(例如 Gateway)。remote：配置 Multicluster Mesh 的 Remote Cluster。empty：不部署任何东西。可以作为自定义配置的基本配置文件。preview：预览文件包含的功能都是实验性。这是为了探索 Istio 的新功能，不确保稳定性、安全性和性能（使用风险需自负）。 defaultdemominimalremoteemptypreview核心组件 istio-egressgateway √ istio-ingressgateway√√ √istiod√√√ √# 给命名空间添加标签，指示 Istio 在部署应用的时候，自动注入 Envoy Sidecar 代理 kubectl label namespace [default] istio-injection=enabled安装 Kubernetes Gateway API CRDKubernetes Gateway API CRD 在大多数 Kubernetes 集群上不会默认安装， 在使用 Gateway API 之前需要安装$ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \ { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.4.0" | kubectl app

二、Istio 官网：https://istio.io/latest/zh/Istio 是一种开源服务网格，可透明地分层到现有的分布式应用程序上。 Istio 的强大功能提供了一种统一且更高效的方式来保护、连接和监控服务。 Istio 是实现负载均衡、服务到服务身份验证和监控的途径 - 几乎无需更改服务代码。包含以下功能：使用双向 TLS 加密、强大的基于身份的身份验证和鉴权在集群中保护服务到服务通信HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡使用丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制支持访问控制、限流和配额的可插入策略层和配置 API集群内所有流量（包括集群入口和出口）的自动指标、日志和链路追踪Istio 服务网格从逻辑上划分为数据平面和控制平面数据平面：由一组被部署为 Sidercar 的智能代理（Envoy）组成，负责协调和控制微服务之间的所有网络通信，同时也收集和报告所有网格流量的遥测数据控制平面：管理、配置代理，进行流量路由

一、服务网格 服务网格（Service Mesh）是一个专用的基础架构层，用于管理分布式应用程序中各个微服务之间的通信。它充当透明且分散的代理网络，并且部署在应用服务旁边，这些代理通常被称为 Sidercar，用于处理服务间的网络调用，限流，熔断，负载均衡等。当微服务（Service）集群扩大到一定规模后，就形成了网格状（Mesh），即 Service Mesh 形态

Helm 参照 b站王晓春老师 helm 课程一、安装官网：https://helm.sh/此处以二进制包安装为例：# K8s 管理节点 wget https://github.com/helm/helm/releases/download/v3.18.3/helm-v3.18.3-linux-amd64.tar.gz.asc tar -zxvf helm-v3.18.3-linux-amd64.tar.gz.asc -C /usr/local/bin ln -s /usr/local/bin/linux-amd64/helm /usr/bin/helm # 查看版本信息 helm version二、常用命令1. 管理类Repository 管理add、list、remove、upgrade、index子命令等Chart 管理create、package、pull、push、dependency、search、show、verify等Release 管理instll、upgrade、get、list、history、status、rollback、uninstall等2. 常用命令示例# repo helm repo list # 列出已添加的仓库 helm repo add [REPO_NAME] [URL] # 添加远程仓库并指定名称 helm repo remove [ROPE_NAME] # 删除仓库 helm repo update # 更新仓库，类似于 apt update helm search hub [xxx] # 从 artifacthub 搜索，类似于 docker search helm search repo [xxx] # 从本地仓库搜索 helm show chart [CHART] # 查看 chart 包的信息 helm show values [CHART] # 查看 chart 包下 values.yaml 的文件内容 # 拉取 helm pull repo/chartname # 拉取最新版本的 chart.tgz 到当前目录下 helm pull chart_URL # 从 url 拉取 helm pull repo/app --version 1.0 --untar # 拉取指定版本并解压 # 安装 helm install [NAME] [CHART] [--version <string>] # 安装指定版本的 chart helm install [CHART] --generate-name # 安装时自动生成 RELEASE_NAME helm install --set key1=value1,key2=value2 [RELEASE_NAME] [CHART] # 动态设置参数 helm install -f values.yaml [RELEASE_NAME] [CHART] # 引用指定文件配置 helm install --debug --dry-run [RELEASE_NAME] [CHART] # 调试但不实际运行，输出调试的结果 # 删除 helm uninstall [RELEASE_NAME] # 删除 release # 查看 helm list # 列出已安装的 release helm status [RELEASE_NAME] # 查看 release 状态 helm get notes [RELEASE_NAME] # 查看 release 的说明 helm get values [RELEASE_NAME] -n [NAMESPACE] > values.yaml # 查看 release 生成的 values 并导出至指定文件 helm get mainfest [RELEASE_NAME] -n [NAMESPACE] # 查看 release 生成的资源清单文件 # 升级和回滚 helm upgrade [RELEASE_NAME] [CHART] --set key=value # 更新 release，同时动态设置参数 helm upgrade [RELEASE_NAME] [CHART] -f chartname/values.yaml # 同上 helm rollback [RELEASE_NAME] [REVISION] # 回滚至指定版本，不指定版本时默认回滚至上一个版本 helm history [RELEASE_NAME] # 查看历史记录 # 打包 helm package chartname/ # 将指定目录下的 chart 打包为 chartname.tgz 包至当前目录下3. 安装 chart 的六种方式By chart reference:helm install mysql xxx/mysqlBy path to a packaged chart:helm install mysql ./mysql-5.7.35.tgzBy path to an unpacked chart directory:helm install mysql ./mysqlBy absolute URL:helm install mysql https://xxx.com/charts /mysql-5.7.35.tgzBy chart reference and repo url:helm install --repo https://xxx .com/charts/mysql mysqlBy oci registries:helm install mysql --version 5.7.35 oci://xxx.com/charts /mysql

Sealos3.0离线部署K8s集群 2022.8.14补充：sealos3.0原部署方式已下线，4.0可以参照官方文档，笔记待补充Sealos离线部署K8s集群准备工具xshell，xftp，centos 7.9，k8s 1.18.9离线安装包开始安装：一、安装系统1. 选择最小安装2. 分区3. 设置账户二、系统设置1. 网络设置集群内服务器设置为静态IP，使用vim修改 /etc/sysconfig/network-scripts/ifcfg-ensxxx# 修改配置文件 vim /etc/sysconfig/network-scripts/ifcfg-ensxxx # 配置静态IP #BOOTPROTO=dhcp BOOTPROTO=static IPADDR=192.168.5.130 GATEWAY=192.168.5.2 NETMASK=255.255.255.0 DEVICE=eth0 MTU=1500 NM_CONTROLLED=no ONBOOT=yes TYPE=Ethernet USERCTL=no ZONE=public DNS1=8.8.8.8修改保存之后重启网络systemctl restart network2. 设置hostnamehostname统一格式为 ==节点名.k8s==如：master.k8s，node1.k8s，node2.k8s# 修改hostname hostnamectl set-hostname master.k8s # 查看修改结果 hostnamectl status # 设置 hostname 解析 echo "127.0.0.1 $(hostname)" >> /etc/hosts3. 更换yum源# 备份原配置文件 cp /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak # 下载阿里云yum curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo # 两条命令任选其一 wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo # 清理缓存 yum clean all # 生成新的缓存 yum makecache添加epel源（如果已存在，同理执行备份替换）# 查看一下系统是否已有epel rpm -qa |grep epel # 如果已存在，卸载以前的epel以免受影响 rpm -e epel-release # 更换为阿里的epel源 wget -P /etc/yum.repos.d/ http://mirrors.aliyun.com/repo/epel-7.repo # 清理缓存 yum clean all # 生成新的缓存 yum makecache4. 挂载数据硬盘无需挂载则跳过此步骤（1）运行fdisk -l查看硬盘详细信息（2）初始化分区执行fdisk /dev/sdc输入p打印分区表，查看分区情况，可以看到，标记处无任何分区信息输入n新建分区输入p再次查看分区表输入w保存退出执行fdisk -l查看已创建的分区（3）创建物理卷执行partprobe /dev/sdc，在不重启系统的情况下重新读取分区表信息# 安装lvm2工具 yum install lvm2 # 创建物理卷 pvcreate /dev/sdc1格式化磁盘# ext4、xfs格式按需选择 mkfs.xfs /dev/sdc1（4）创建挂载点，并挂载磁盘mkdir /data mount /dev/sdc1 /data执行df -Th可查看挂载情况（5）设置系统开机自动挂载磁盘执行blkid /dev/sdc1查看磁盘的uuid编辑/etc/fstab文件，在末尾添加新增的磁盘信息# UUID [挂载点] [磁盘类型] defaults 0 0 # 二者任选其一 # /dev/sdb1 /data xfs defaults 0 0 执行mount -a检查配置注：添加配置文件保存后一定要mount -a检查通过再执行reboot重启5. 同步集群时间执行crontab -e，在末尾添加以下cron定时任务，集群中的每个节点都必须执行# 每天零点零一分执行时间同步任务 01 00 * * * /usr/sbin/ntpdate time1.aliyun.com > /dev/null 2>&1 &保存后显示定时任务创建成功执行contab -l，可查看已创建的任务6. 关闭防火墙systemctl stop firewalld # 临时关闭，重启失效 systemctl disable firewalld # 永久关闭7. /usr/local/bin 全局命令设置执行vim ~/.bashrc，在末尾添加export PATH="$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:"保存后执行刷新读取命令source .bashrc此项跟后续安装sealos，kubens，k8sreload工具有关，若不使用该工具则跳过三、准备环境# 创建目录 # k8s 部署目录 mkdir -p /home/xxx/deploy # 应用目录 mkdir /home/xxx/deploy/xxx # 资源目录 mkdir /home/xxx/res # 插件目录 mkdir /home/xxx/res/plugin # 应用基础镜像目录 mkdir /home/xxx/res/images # 应用业务镜像目录 mkdir /home/xxx/res/busi mkdir /home/xxx/res/busi/service # 目录结构 └── xxx ├── deploy # 项目部署文件 │   └── xxx └── res # 资源目录 ├── busi # 应用业务镜像目录 ├── images # 基础镜像 ├── kube1.18.9.tar.gz # k8s离线包 ├── plugin # 插件 ├── service # 服务端 └── web # 客户端四、安装k8sk8s版本选择1.18.91.安装sealossealos是k8s一键安装工具，官网地址：https://www.sealyun.com/# 下载并安装sealos, sealos是个golang的二进制工具，直接下载拷贝到bin目录即可, release页面也可下载 wget -c https://sealyun.oss-cn-beijing.aliyuncs.com/latest/sealos && chmod +x sealos && mv sealos /usr/local/bin/ # 上传离线资源包到主节点2.初始化集群sealos init 命令解释， https://www.sealyun.com/instructions# 一主双从Kubernertes集群 sealos init --master 192.168.5.130 \ --node 192.168.5.131 \ --node 192.168.5.132 \ --user root \ --passwd '123456' \ --pkg-url /home/xxx/res/kube1.18.9.tar.gz \ --version v1.18.92.1检查集群状态kubectl get nodes -o wide2.2修改端口范围k8s NodePort 端口范围设置为30000-39999# 编辑kube-apiserver.yaml vim /etc/kubernetes/manifests/kube-apiserver.yaml # 添加端口配置到 spec.containers.command.kube-apiserver - --service-node-port-range=30000-399992.3设置master支持部署pod此项根据实际情况选择，如果不需要master支持pod则跳过#允许master节点部署pod kubectl taint nodes --all node-role.kubernetes.io/master- #如果不允许调度 kubectl taint nodes master1 node-role.kubernetes.io/master=:NoSchedule #污点可选参数 # NoSchedule: 一定不能被调度 # PreferNoSchedule: 尽量不要调度 # NoExecute: 不仅不会调度, 还会驱逐Node上已有的Pod2.4 node节点添加标签格式要求："xxx/role"=master,"xxx/role"=node1,"xxx/role"=node2# 查看节点标签详细信息 kubectl get nodes --show-labels # 设置标签 kubectl label nodes master.k8s "xxx/role"=master kubectl label nodes node1.k8s "xxx/role"=node1 kubectl label nodes node2.k8s "xxx/role"=node22.5 修复子节点kubectl 命令不可用此项按需选择，如果无需子节点支持kubectl命令则跳过# 拷贝master节点/etc/kubernetes/admin.conf文件至node节点 scp /etc/kubernetes/admin.conf root@192.168.5.131:/etc/kubernetes/ # 在对应的node节点执行以下命令 echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile source ~/.bash_profile2.6 k8s tab键修复# 安装bash-completion yum install -y bash-completion # 编辑~/.bashrc vim ~/.bashrc # 在末尾添加以下行 source <(kubectl completion bash) # 最后运行 source ~/.bashrc source /etc/profile # 对应的node节点也需运行上面2行命令或退出重新登录2.7 更换docker根文件目录docker文件默认路径是 /var/lib/docker，检查该目录磁盘空间是否足够，根据实际情况修改。注：如果docker根目录文件所处的磁盘空间较小，一定要将docker根文件目录更换至空间较大的数据盘下修改docker文件目录# 停止所有节点上的docker systemctl stop docker # 编辑 /etc/docker/daemon.json，修改data-root目录 vim /etc/docker/daemon.json # 移动docker的数据文件到新目录 mv /var/lib/docker /data/docker # 启动 systemctl start docker注：所有节点依次执行，修改此项尽量不要使用 xshell发送输入命令到所有会话 功能，网络延迟对同时发送命令可能会产生较大的影响3. 添加k8s拉取harbor镜像账户3.1添加docker仓库地址# 编辑daemon.json vim /etc/docker/daemon.json { "insecure-registries": "harbor.xxx.com" }3.2 创建k8s登录harboa.命令行方式创建kubectl create secret docker-registry approval-docker-harbor \ --docker-server=harbor.xxx.com \ --docker-username=xxx\ --docker-password='123456'b.yaml方式创建apiVersion: v1 kind: Secret metadata: namespace: xxx name: approval-docker-harbor type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: xxxxxxxxx4. 安装ingress注：ingress官方建议将ingress部署至master节点，该部署手册中未开启master支持pod调度的功能，在执行部署命令之前需先执行# 2.4节已执行过该命令，无需重复添加 kubectl label nodes master.k8s "xxx/role"=mastermaster节点添加标签后需编辑 ingress.yaml 文件，执行vim ingress.yaml，添加nodeSelector标签，将该pod直接调度到master节点最后执行部署# 进入到ingress文件夹 cd /home/xxx/res/plugin/ingress kubectl apply -f ingress.yaml5. 安装Kuboard此处安装Kuboard v2版本，Kuboard官网地址：https://kuboard.cnkubectl apply -f https://kuboard.cn/install-script/kuboard.yaml kubectl apply -f https://addons.kuboard.cn/metrics-server/0.3.7/metrics-server.yaml # 查看Kuboard运行状态 kubectl get pods -l k8s.kuboard.cn/name=kuboard -n kube-system获取登录Token（注意保存token，切勿泄露）# 在master节点执行以下命令 # 管理员 echo $(kubectl -n kube-system get secret $(kubectl -n kube-system get secret | grep ^kuboard-user | awk '{print $1}') -o go-template='{{.data.token}}' | base64 -d) # 只读用户（无操作权限） echo $(kubectl -n kube-system get secret $(kubectl -n kube-system get secret | grep ^kuboard-viewer | awk '{print $1}') -o go-template='{{.data.token}}' | base64 -d) Kuboard管理地址：192.168.5.130:32567 （任意节点ip + 端口均可访问）6. 安装NFSnfs-client-provisioner.yml需要添加nodeSelector节点选择标签6.1 安装NFS服务端# 安装nfs相关工具 yum install -y nfs-utils # 在文件/etc/exports中添加以下内容(vim /etc/exports) #格式：[共享目录]:[共享主机](权限功能) vim /etc/exports /data/nfs 192.168.0.0/16(rw,no_root_squash,no_all_squash,sync,anonuid=501,anongid=501,fsid=0) localhost(rw) # 创建nfs共享目录 mkdir /data/nfs -p # 启动nfs systemctl enable rpcbind systemctl enable nfs-server systemctl start rpcbind systemctl start nfs-server exportfs -r #检查nfs创建结果 exportfs #输出结果如下 /data/nfs <world>6.2 安装NFS客户端yum -y install nfs-utils # 启动 systemctl start nfs-utils systemctl enable nfs-utils #查看相关信息 rpcinfo -p #测试挂载，单节点不需要这步 mount [nfs服务ip]:[nfs共享路径] [客户机挂载目录]6.3 k8s部署NFS添加nodeSelector节点选择标签（同理安装ingress）# 添加node节点标签 # 若2.4节已执行过该命令，则此处无需重复执行 kubectl label nodes node1.k8s "xxx/role"=node1 # 进入到nfs文件夹 cd /home/xxx/res/plugin/nfs # 修改nfs服务地址，同时添加nodeSelector节点选择标签，参考下图 vim nfs-client-provisioner.yml # 执行部署 kubectl apply -f nfs-client-provisioner.yml kubectl apply -f class.yml kubectl apply -f rbac.ymlNFS部署在default命名空间下，执行kubectl get pod检查NFS状态至此，k8s基础环境部署完毕五、应用1. 上传部署文件将yaml配置文件上传至/home/xxx/deploy/xxx2.执行对应服务的yaml文件# 部署 kubectl apply -f xxx.yaml # 或者执行 k8sreload xxx.yaml # 以上命令二选一 # 删除pod kubectl delete -f xxx.yaml六、其他1. 部署pod至指定节点在具体的yaml文件中指定 nodeSelectorapiVersion: apps/v1 kind: Deployment spec: template: spec: nodeSelector: #node节点标签选择器 "xxx/role": master #node节点标签内容2. 设置容器使用secreta. 在具体的xxx.yaml中设置apiVersion: v1 spec: template: spec: imagePullSecrets: - name: approval-docker-harborb. 设置默认账户方式此方式是设置给对应的namespace（命名空间）下的用户，添加 imagePullSecrets，无需在部署文件中再使用，注：namespace为空对应默认用户(default)# 命令方式 kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "docker-harbor-secret"}]}' -n kubernetes-dashboard# yaml文件方式 apiVersion: v1 kind: ServiceAccount metadata: name: default namespace: #NAME_SPACE# imagePullSecrets: - name: docker-harbor-secret