小白带你去上云-容器服务网格实践

原创

白鹏飞

修改于 2021-03-04 19:05:49

8450

修改于 2021-03-04 19:05:49

文章被收录于专栏：拥抱云原生拥抱云原生

1. 前言

大家好，这里是小白带你去上云系列的第一篇。

随着容器技术、微服务架构的普及，越来越多的团队开始走向Service mesh之路。

今天，我们就以腾讯云容器服务的，服务网格为例，来重点感受下Istio 服务治理的魅力。

内容略多，小白同学参照Istio官网文档，一步步操作后才有一丝感觉。

读者朋友，如果有Kubernetes 基础、Istio 学习经历，理解起来可能比较容易。

2 技术铺垫

2.1 容器

通过将业务运行环境，打包成一个镜像，从而实现业务快速复制、独立运行，容器技术的出现极大地提高了业务部署、扩容的灵活性。与此同时，以Docker、Containerd 为代表的容器运行时，也让我们感受到了资源隔离、虚拟化的成本优势。

2.2 Kubernetes

目前业界流行的容器编排系统，不仅支持编排容器，同时支持网络拓展、存储调度。自从Google 将其开源并到贡献CNCF之后，Kubernetes已经成为目前容器编排的事实标准，并且由此衍生另一个概念：云原生。

曾经在一些公众号上，小白同学也看到过云原生操作系统的声音：诸位以后，可能要面向Kubernetes编程！其流行、火热程度，可见一斑。

2.3 Istio

今天学习的主角，服务治理领域的新星，能够提供服务注册与发现、访问控制、流量路由、观测追踪、熔断限流、安全管控等诸多功能。

相比其他选手，Isito 又自带多语言支持、业务无侵入等特性，对于研发、运维同事来说，这感觉确实酸爽。

小结：

查看Istio官网文档会发现：Istio 主要运行在Kubernetes 环境中，针对容器化的应用，进行服务治理。三者大致是这么一个关系，可以先感觉一下。

3 服务网格体验

Istio 官网有个bookinfo示例，清晰明了的讲述了Istio 的相关功能，新手入门效果很好。

接下来，我们结合腾讯云-》容器服务-》服务网格来具体感受下（目前内测中，估计后续全量上线）。

3.1 新建容器集群

首先，我们要有一个容器集群。这里，我们在腾讯云-》容器服务这里，快速新建一个。

资源选择：期间小白，选配了TKE托管模式，4台低配机器（2核心CPU-4GB/8GB内存-50GB磁盘-1MB带宽机器）来做体验。
网络配置：与此同时，小白也专门新建了对应的VPC以及子网——个人感觉比较清爽。
云原生监控：运维中心模块下的云原生监控，是基于Prometheus+Grafana 开发的云端产品，作为容器服务的绝佳伙伴，支持一键式安装，建议使用起来（当然，非必选）。

容器集群创建以后，为了本地访问方便，小白同学开启了API Server 的外网访问+内网访问。示意图：

如果操作熟练的话，容器集群3-5min 就可以创建出来了。期间配置过程，不再详细说明。

3.2 新建服务网格

进入容器服务-》服务网格-》新建实例

说明：

（1）网络模式：目前支持2种，托管网格+独立网格。

托管网格：网格控制面与相关支撑组件由腾讯云管理和维护。

独立网格：网格控制面组件部署于指定集群，腾讯云参与管理和维护。

（2）Egress 流量模式：Register Only + Allow Any 两种可选。

这个跟Istio egress 原生特性一致。

（3）调用追踪采样率：可参考前端提示说明，生产环境建议设置为1%。

（4）服务发现：这里需要添加集群，而且可以添加多个集群（有主集群、子集群之分）。

主集群：网格控制面组件部署与运行的集群。

子集群：仅需部署部分组件，可选择与控制面集群在相同或不同地域。

这里，我们从简单的入手，只添加刚刚创建的TKE集群，作为主集群。

（5）高级监控：云原生监控这里，建议开启，也可以选择创建后再开启。

（6）边缘代理网关：默认启用。

ingress gateway：外部请求访问网格内部服务入口。

egress gateway：内部请求访问网格外部服务的统一出口。

（7）istio-system 命名空间：服务网格创建成功后，小白同学在本地终端访问TKE集群（mac 环境，已配置TKE集群外网访问），可以发现多了一个isito-system 的namespace。

与此同时，平台初始化了ingress-gateway 组件，并创建了一个load balancer 类型的 svc，为其自动分配了外网VIP 120.53.213.160。后续，该VIP将成为bookinfo 服务的访问入口。

$ kubectl get ns
NAME                     STATUS   AGE
default                  Active   8d
istio-system             Active   6d17h
kube-node-lease          Active   8d
kube-public              Active   8d
kube-system              Active   8d
prom-mzypha5v            Active   8d
tke-cluster-inspection   Active   8d

$ kubectl get pods -n istio-system 
NAME                                              READY   STATUS    RESTARTS   AGE
istio-ingressgateway-586c744d79-k8d6m             1/1     Running   0          6d17h

kubectl get svc -n istio-system 
NAME                             TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                                                      AGE
istio-crd                        ClusterIP      172.16.255.81    <none>           61011/TCP                                                    6d17h
istio-ingressgateway             LoadBalancer   172.16.252.146   120.53.213.160   80:31236/TCP,15021:32645/TCP,15443:31262/TCP                 6d17h
istiod-1-6-9                     ClusterIP      172.16.253.169   <none>           15012/TCP,443/TCP                                            6d17h
zipkin                           ClusterIP      172.16.253.183   <none>           9411/TCP                                                     6d17h

3.3 bookinfo 部署示例

3.3.1 初步认知

参考官方网站，bookinfo 示例包含4个微服务，相关说明如下：


productpage. 这个微服务会调用 details 和 reviews 两个微服务，用来生成页面。
details. 这个微服务中包含了书籍的信息。
reviews. 这个微服务中包含了书籍相关的评论。它还会调用 ratings 微服务。
ratings. 这个微服务中包含了由书籍评价组成的评级信息。

reviews 微服务有 3 个版本：
v1 版本不会调用 ratings 服务。
v2 版本会调用 ratings 服务，并使用 1 到 5 个黑色星形图标来显示评分信息。
v3 版本会调用 ratings 服务，并使用 1 到 5 个红色星形图标来显示评分信息。

3.3.2 业务架构

3.3.3 服务部署

（1）这里，我们直接参考官网部署yaml 文件，实际操作时，可以将文件下载到本地，再apply 发布到TKE 容器集群中。

$ kubectl apply -f bookinfo.yaml

（2）平台新建的服务网格，默认default 命名空间自动注入sidecar。用户可以在服务-》sidecar 自动注入管理，这里进行更新。如下图：

查看default 命名空间下业务信息：

$ kubectl get pods 
NAME                              READY   STATUS    RESTARTS   AGE
details-v1-5974b67c8-x4v66        2/2     Running   2          4d21h
productpage-v1-797898bc54-g2fjf   2/2     Running   0          4d21h
ratings-v1-c6cdf8d98-7g6nm        2/2     Running   0          4d21h
reviews-v1-8bdc65f7b-d4pwp        2/2     Running   2          4d21h
reviews-v2-868d77d678-wgg7c       2/2     Running   2          4d21h
reviews-v3-6c9b646cb4-cb9zw       2/2     Running   2          4d21h
$ kubectl get deploy 
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
details-v1       1/1     1            1           4d21h
productpage-v1   1/1     1            1           4d21h
ratings-v1       1/1     1            1           4d21h
reviews-v1       1/1     1            1           4d21h
reviews-v2       1/1     1            1           4d21h
reviews-v3       1/1     1            1           4d21h
$ kubectl get svc
NAME                TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
details             ClusterIP      172.16.255.179   <none>        9080/TCP         4d21h
kube-user           LoadBalancer   172.16.252.72    10.3.0.3      443:30047/TCP    8d
kubernetes          ClusterIP      172.16.252.1     <none>        443/TCP          8d
productpage         ClusterIP      172.16.253.209   <none>        9080/TCP         4d21h
ratings             ClusterIP      172.16.255.182   <none>        9080/TCP         4d21h
reviews             ClusterIP      172.16.253.187   <none>        9080/TCP         4d21h

这里可以看到：对应的deployment、 pod、svc 已经在集群创建成功。

如果足够细心，可以发现：

业务pod 多了一个istio-init 的初始化容器，同时多了一个istio-proxy 的sidecar 容器。
这里的reviews 服务，创建了1个service，但是3个版本却使用了3个deployment。

为什么如此设计、使用？小白同学觉得这是个好问题～大家可以一起思考下。

3.4 确认ingress ip+port

这一步，相对简单了。之前，我们提到过边缘代理网关 ingress-gateway。

kubectl get svc -n istio-system 
NAME                             TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                                                      AGE
istio-crd                        ClusterIP      172.16.255.81    <none>           61011/TCP                                                    6d18h
istio-ingressgateway             LoadBalancer   172.16.252.146   120.53.213.160   80:31236/TCP,15021:32645/TCP,15443:31262/TCP                 6d18h
istiod-1-6-9                     ClusterIP      172.16.253.169   <none>           15012/TCP,443/TCP                                            6d18h
zipkin                           ClusterIP      172.16.253.183   <none>           9411/TCP                                                     6d18h

120.53.213.160:80 就是后续使用的ingress ip+port ，也就是bookinfo 的公网访问地址。

3.5 创建gateway

参考官方文档，为bookinfo 定义ingress 网关：

$ kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml

确认网关创建完成：

$ kubectl get gateway -o wide
NAME         AGE
book-info    3d23h

$ kubectl get gateway -o yaml 
apiVersion: v1
items:
- apiVersion: networking.istio.io/v1beta1
  kind: Gateway
  ...
  spec:
    selector:
      app: istio-ingressgateway
      istio: ingressgateway
    servers:
    - hosts:
      - '*'
      port:
        name: HTTP-80-tell
        number: 80
        protocol: HTTP

说明：

gateway 作为运行在网格边界的Envoy 代理，可以为网格管理入站和出站流量。
网关如果要工作，须绑定到对应的虚拟服务（virtual service）上——3.6 小节会给出相应示例。

这里，我们转到前端页面，在Gateway 目录下，可以看到book-info 网关，相应的公网地址可见：120.53.213.160

3.6 创建virtual service

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
  - "*"
  gateways:
  - bookinfo-gateway
  http:
  - match:
    - uri:
        exact: /productpage
    - uri:
        prefix: /static
    - uri:
        exact: /login
    - uri:
        exact: /logout
    - uri:
        prefix: /api/v1/products
    - uri:
        prefix: /
    route:
    - destination:
        host: productpage
        port:
          number: 9080

book-info virtual service 定义包含在3.5 小节的部署文件中。这里单独拿出来，说明下：

bookinfo 虚拟服务，绑定了网关 bookinfo-gateway，同时定义服务的路由。
match 以上条件时，istio 将请求路由到 productpage 服务的9080 端口上。
路由规则：virtual service 的路由规则，按从上到下进行选择。服务定义的第一条规则拥有最高优先级，不满足条件的流量均路由到一个默认的目标。这里默认目标是productpage 服务。
部分改动：match 路由这里，添加了一条即：prifix 为 / 的请求，也路由到productpage 服务——后续浏览器访问productpage，加载前端静态文件会用到。

至于virtual service 的特性、存在的意义，大家可以参考下官网说明，体会下基于virtual service 进行 A/B测试，金丝雀发布的玩法。

回到前端，我们可以看到book-info 已经创建：

说明：

小白同学，在学习过程中，先是按照官网文件apply 学习实践，而后又删除重建，深刻体会了几把。所以这里截图上，部分gateway，virtual service 名称有些许改动，跟apply 文件不太一致，读者朋友如果有困惑，请忽略。

3.7 集群外访问应用

经历以上步骤，现在可以访问服务页面了。

终端访问效果

$ curl -s http://120.53.213.160/productpage | grep -o "<title>.*</title>"
<title>Simple Bookstore App</title>

浏览器访问效果

多版本访问效果

此时刷新页面，浏览器会呈现不同的reviews 服务版本，先睹为快。

reviews v1:

reviews v2:

reviews v3:

说明：

服务出现这种情况，是因为，我们还没有使用isito 来控制版本的路由。

3.8 应用目标规则（destination rule）

3.8.1 应用规则

参考官网文档，应用默认目标规则（实际操作时，请先下载再apply）。

$ kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: productpage
spec:
  host: productpage
  subsets:
  - name: v1
    labels:
      version: v1
...

3.8.2 规则理解

关于目标规则，其功能可以参考官网说明。小白同学的理解：

虚拟服务：绑定网关，并且将流量路由到目标地址——不过这个目标地址是虚拟的。
目标规则：配置目标的流量管理，应用于真实的服务，如kubernetes 系统的service 概念。支持负载均衡模型、TLS安全配置、熔断器配置。
版本划分：看下官网说明

特别的，您可以使用目标规则来指定命名的服务子集，例如按版本为所有给定服务的实例分组。然后可以在虚拟服务的路由规则中使用这些服务子集来控制到服务不同实例的流量。

通俗的理解，业务侧发布的版本，可以通过destinattion rule 来定义，并划分子集。如果定义划分呢？简单看下文档，就是kubernetes 范畴上的 label 标签。这里，反思下集群中reviews 三个版本 version=v1/v2/v3 的deployment ，是不是有点感觉了。

$ kubectl get deploy -o wide |grep -i reviews
reviews-v1       1/1     1            1           4d23h   reviews       docker.io/istio/examples-bookinfo-reviews-v1:1.16.2       app=reviews,version=v1
reviews-v2       1/1     1            1           4d23h   reviews       docker.io/istio/examples-bookinfo-reviews-v2:1.16.2       app=reviews,version=v2
reviews-v3       1/1     1            1           4d23h   reviews       docker.io/istio/examples-bookinfo-reviews-v3:1.16.2       app=reviews,version=v3

3.8.3 回到前端

服务网格-》服务-》进入具体服务详情页面，就可以编辑对应的destination rule 了。

从前端看，主要是服务版本、流量策略两块。

假如业务侧，在default 命名空间，新增了productpage v2版本的部署，同时打上了version=v2的标签。

这里，就可以编辑服务版本，进行新增，如下图：

4 业务场景拓展

4.1 配置请求路由

上述微服务部署成功后，刷新几次页面，就会发现bookinfo reviews 的版本变化。如果想给服务配置默认、或者固定的的路由规则，就需要为服务设置相应版本的virtual service。

参考官网文档：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: productpage
spec:
  hosts:
  - productpage
  http:
  - route:
    - destination:
        host: productpage
        subset: v1
...
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
---

这里以reviews 为例，默认版本为v1. apply 以上配置到容器集群，多次刷新后，可以发现稳定的reviews v1 页面：

回到前端，编辑virtual service reviews 默认为v3，即可固定到v3 版本。

具体效果不再截图。

4.2 流量转移、分发

针对日常常见的版本升级，我们可以先创建一个v1 版本部署，再创建一个v2 版本部署。然后通过配置服务的virtual service ，来进行现网流量切分。参照官网的reviews 示例：

$ kubectl get virtualservice reviews -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
  ...
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 50
    - destination:
        host: reviews
        subset: v3
      weight: 50

说明：

（1）流量转移、切分：这里v1 版本分配50% 流量，v3版本分配了50%流量。

访问ingress 网关地址 http://120.53.213.160/productpage?u=normal ，即可看到效果。

（2）如果业务方，认为v3版本服务已经稳定，就可以权重100%，全量切过去。

（3）独立升级：

使用 Istio，两个版本的 reviews 服务可以独立地进行扩容和缩容，而不会影响这两个服务版本之间的流量分发。

这个特性，小白同学觉得确实很香。因为kubernetes depoyment 滚动升级，是不支持如此准确的流量切分的。

4.3 熔断、限流

参考官方文档，熔断机制可以使应用程序获得，应对故障、流量高峰、以及其他未知网络因素的能力。

通过主动熔断，应用程序无疑提高了系统的健壮性，避免被击垮导致的服务不可用。

4.3.1 部署熔断示例

部署httpbin服务：

$ kubectl apply -f samples/httpbin/httpbin.yaml

部署负载测试应用fortio（小白同学喜欢直接apply 文件到集群，而且本地也没有装istioctl）：

$ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/sample-client/fortio-deploy.yaml)

4.3.2 配置熔断器

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100
EOF

简单说明：

熔断器主要包括：连接池 connectionPool ，以及健康检测 outlierDetection。
触发熔断条件：当并发的连接和请求超过1个，istio-proxy 就会阻止后续请求、连接。

4.3.3 熔断触发示例

参照官方说明，小白同学，本地运行的pod 为 fortio-deploy-7cb865f87f-5m56s ，测试结果如下：

$ kubectl exec -it fortio-deploy-7cb865f87f-5m56s -c fortio -- /usr/bin/fortio load -c 3 -qps 0 -n 30 -loglevel Warning http://httpbin:8000/get
13:01:02 I logger.go:127> Log level is now 3 Warning (was 2 Info)
Fortio 1.11.3 running at 0 queries per second, 2->2 procs, for 30 calls: http://httpbin:8000/get
Starting at max qps with 3 thread(s) [gomax 2] for exactly 30 calls (10 per thread + 0)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
13:01:02 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503)
Ended after 98.968633ms : 30 calls. qps=303.13
Aggregated Function Time : count 30 avg 0.0039701271 +/- 0.01026 min 0.000411112 max 0.056732293 sum 0.119103813
# range, mid point, percentile, count
>= 0.000411112 <= 0.001 , 0.000705556 , 50.00, 15
> 0.001 <= 0.002 , 0.0015 , 53.33, 1
> 0.002 <= 0.003 , 0.0025 , 73.33, 6
> 0.003 <= 0.004 , 0.0035 , 93.33, 6
> 0.016 <= 0.018 , 0.017 , 96.67, 1
> 0.05 <= 0.0567323 , 0.0533661 , 100.00, 1
# target 50% 0.001
# target 75% 0.00308333
# target 90% 0.00383333
# target 99% 0.0547126
# target 99.9% 0.0565303
Sockets used: 21 (for perfect keepalive, would be 3)
Jitter: false
Code 200 : 10 (33.3 %)
Code 503 : 20 (66.7 %)
Response Header Sizes : count 30 avg 76.733333 +/- 108.5 min 0 max 231 sum 2302
Response Body/Total Sizes : count 30 avg 444.73333 +/- 288.1 min 241 max 853 sum 13342
All done 30 calls (plus 0 warmup) 3.970 ms avg, 303.1 qps

说明：这里看到了66.7% 左右的503 ，即熔断效果生效。

4.3.4 回到前端

服务网格-》服务-》httpbin，就可以看到对应的流量策略了：

说明：部分参数本地测试中，可能有部分改动，与官方apply 文件配置不一致，请忽略。

4.4 故障注入

参考官方文档，可以发现故障注入，也是配置在对应的virtual service 上。

这里，我们直接切到前端：

服务网格-》virtual service-》编辑路由-》打开高级配置，即可编辑故障注入策略。

相关测试样例，不再书写，有兴趣的朋友可以看下官网文档。

4.5分布式追踪

参考官网文档说明：

分布式追踪可以让用户对跨多个分布式服务网格的 1 个请求进行追踪分析。这样进而可以通过可视化的方式更加深入地了解请求的延迟，序列化和并行度。

这里，我们回到前端，来看下服务网格的网络拓扑。

点击拓扑图service，可以看到相应的采样信息，监控数据等，如：

连续访问productpage 服务，才可以看到连续的监控曲线、拓扑数据——供参考。

4.6 云原生监控

用户侧，之前如果有创建云原生监控实例，并且跟服务网格关联，这时就可以直接登陆Grafana 系统，查看Istio 对应的监控面板。简单截图如下：

Istio 面板这里，系统默认内置了一些dashboard，用户侧有需要可以自定义，不再赘述。

4.7 示例拓展

之前bookinfo 实例，已经分配了一个ingress-gateway，绑定了特定的vip+80 端口。如果业务较多，新业务需要其他的80端口监听，该怎么办呢？

小白同学，带着这个问题，简单摸索了下：

（1）新建边缘网关，系统自动分配VIP：

（2）创建Gateway，绑定边缘网关：

（3）部署新业务

部署新业务、新service -》创建destination rule-》创建virtual service 、绑定网关。

之后的步骤就跟bookinfo 很类似了。这里可以看到，小白同学创建的java-shine 网关，分配了一个新的vip+port。

举一反三，由一到多，有兴趣的朋友，可以在腾讯云控制台亲身体验下。

4.8 期间问题排查

（1）镜像下载问题：bookinfo示例，部分镜像可能下载不下来，用户可尝试换下就近的镜像，比如腾讯云Hub上镜像。

（2）服务访问503问题：这个问题，调试中很常见。建议检查下kubernetes svc 端口配置、virtual service 的路由（从上到下有优先级配置）。

（3）服务访问404问题：建议检查下gateway 的host ，以及 virtual service 的host 。部分情况下，如访问一个不存在的路径，前端返回404是正确的，可忽略。

（4）80端口复用问题：可以创建多个边缘代理网关（ingress-gateway），然后参考bookinfo 示例部署，具体可以参考下4.7 小节。

5 总结

通过本文的介绍，诸位朋友想必对Istio、腾讯云容器服务网格，有了新的认识，以下简单说下个人理解：

5.1 个人见解：

》技术栈庞大：从最基础的操作系统、网络到上层的容器运行时、Kubernetes基础平台、Service mesh ，再到业务应用层，业务环境涉及的技术栈，确实很多。

》技能要求更高：相应地，运维技能要求越来越高。一个普通问题的定位，可能要涉及好多知识。是不是感觉，学不动了～？

5.2 上云特点：

（1）相对友好、灵活的前端：纯命令行或者yaml 操作，效率还是略低，而且容易出错。

（2）完善的配套和基础设施：创建TKE容器集群、云原生监控、服务网格，可谓是一站式服务。3-5min 创建一个高可用集群，这感觉还是很酸爽的。

（3）配套的技术支持，与售后服务：人的精力总归是有限，当系统越来越庞大，还是要有专业团队支持、跟进，业务运营才能更安心。

6 参考资料

istio：https://istio.io/v1.6/zh/docs/

腾讯云：https://console.cloud.tencent.com/tke2/mesh

潜心容器，拥抱云原生。欢迎大家留言评论，交流共勉。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

容器服务

容器

微服务

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

容器服务

容器

微服务

登录后参与评论

0 条评论

热度