Getting Started with Kubernetes
作者：禅与计算机程序设计艺术
1.简介
概要
作为开源平台工具包,Kubernetes主要用于自动化部署、扩展和管理容器化应用.它支持用户以声明的方式描述运行环境所需的配置信息, 并据此自动生成相应的部署步骤, 实现对资源的优化配置以及系统的高效运行.该系统提供包括但不限于以下功能: 从资源管理方面看, 提供CPU、内存以及存储设备等资源的配置选项; 在服务管理方面, 提供定位现有服务的机制; 在负载均衡方面, 提供自动平衡请求流量的能力; 在弹性伸缩方面, 根据负载自动调整资源分配策略.这些功能还可以与其他云计算平台或私有云环境无缝对接.基于其高度抽象化的设计理念以及广泛的兼容性特点,Kubernetes迅速成为 container orchestration领域的事实标准.
本文主要采用通俗易懂的语言，并辅以具体实例来帮助读者认识Kubernetes的整体框架、工作原理及其主要应用场景
本文主要采用通俗易懂的语言，并辅以具体实例来帮助读者认识Kubernetes的整体框架、工作原理及其主要应用场景
作者简介
李军目前在阿里巴巴集团国际站SRE团队中任职秉持着对容器技术和微服务架构的专业理解他凭借多年的实践经验在软件开发与运维领域积累了深厚的造诣个人技术博客位于http://www.paddyyoung.com/
2.基本概念术语说明
2.1 Kubernetes概述
Kubernetes是一款开源且功能强大的容器集群管理系统软件。它提供了一个分布式平台环境，在公有云服务、私有云环境以及本地数据中心之间实现了统一的一致性调度与管理能力。该软件帮助您高效地管理和维护 containerized应用程序，并支持批量任务提交与调度、资源按需分配与故障自愈等关键功能。此外，在跨多云架构下运行良好，并具备弹性扩展的能力，并可处理数万个节点以及海量的数据存储量。
Kubernetes的主要组件包括:
- Master节点：Master节点作为集群的核心管理界面，整合了API服务器、调度器以及控制器管理层。该节点主要负责集群的整体协调、资源分配以及处理调度相关的事件；
- Node节点：Node节点是指集群中的作业机器，在这里运行容器化应用以及Pod实例，并且也承担着Master节点的部分职责；它是一个集成化的系统组件；
- Pod：Pod是Kubernetes体系结构的基本执行单元，在同一命名空间内与其它Pod共享资源与网络地址；每个Pod由一个或多个容器组成，并根据配置实现灵活的应用部署；
- Deployment：通过部署机制能够动态地创建和更新应用状态；它允许对Pod的状态进行声明式的管理和回滚策略的配置；
- Service发现机制通过Service组件实现了服务的稳定路由能力；无论处于何种网络环境配置下，都能准确地将客户端请求路由至对应的Pod实例上；
- Volume提供了持久化的存储解决方案；无论是用于存储数据库或者缓存相关内容都需要依赖Volume组件来保证数据的一致性和可用性
2.2 Kubernetes架构
下图展示了一个Kubernetes集群的整体架构：
Kubernetes的架构可分为两个层次：管理层面由 Master 节点与 Worker 节点构成，在此基础之上配置了系列资源规范（包括 Pod、ReplicaSet 和 Service）。支撑层位于第一层之上，并通过 RESTful API 接口实现了对这些资源对象的统一规范与管理。在基础设施之外提供了一系列辅助功能模块来满足各种需求。如日志收集、性能监控和故障定位等功能。
2.3 Kubernetes对象模型
注：改写说明
- Pod ：Kubernetes的核心组件之一是Pod（即作业体），它是由一组容器组成的独立运行实体，在同一命名空间下共享资源；
- Replication Controller ：该组件负责控制Pod的复制数量及其副本的生命周期管理；
- Service ：Service是Kubernetes的服务发现机制模块，其主要作用是实现服务发现功能；
- Namespace ：通过Namespace机制可对不同租户、项目的资源进行区分，并确保它们之间不会产生干扰；
- Label ：Label是一种键值对数据标记方式，在资源管理中常用于实现选择器功能；
- ConfigMap ：该组件主要用于存储持久化的配置信息，并通过引用的方式将这些配置传递给相关的Pod；
- Secret ：Secret是用来保护敏感信息的数据存储方案，在系统中起到保密作用；
- Volume ：Volume组件能够提供持久化的数据存储能力，并支持多种存储策略以满足不同需求；
通过将这些实体整合在一起, 我们能够构建出多种复杂的架构. 该模型能够显著增强集群在可管理性. 稳定性和扩展性方面的性能.
2.4 Kubernetes控制器
Kubernetes中的控制器扮演着关键角色，在分布式系统中发挥核心作用。该系统中的控制器主要负责协调各节点上Pod的状态变化，并通过动态调整实现集群内的均衡负载分配。为了实现这一目标，控制器一般按照功能划分主要可分为两种类型：一种是基于状态机的设计模式；另一种是基于事件驱动机制的操作方案。
*kube-controller-manager 作为 Kubernetes 的核心控制器进程，在容器化部署中发挥着关键作用。其主要职责是维持集群运行的健康状况，并管理包括Pod、Replication Controller和Endpoint对象在内的各种资源实体。该进程持续监控当前运行状况与预期目标，并采取措施修正系统偏差；以确保所有资源均能稳定在预设的理想状态下运作。
*cloud-controller-manager 作为 Kubernetes 在云计算环境中的功能扩展模块，在保障基础云计算资源稳定运行方面发挥着重要作用。其主要任务是维护底层 cloudscale 负荷均衡服务器以及存储虚拟化组件等基础设施设备的状态；通过持续监控并优化这些关键组件的工作状态来提升整体系统的性能。
2.5 Kubernetes组件及其特性
Kubernetes包含众多功能模块，并且这些模块之间存在错综复杂的关系网络。以下将介绍几种常见的Kubernetes组件及其特点：
- kubelet：kubelet 是 Kubernetes 核心组件之一，负责初始化并调度集群中的 Docker 容器。它通过从 apiserver 获取PodSpecs信息下载镜像文件，并依据 manifest 文件启动容器，并将容器状态上报给 apiserver。
- kube-proxy：kube-proxy 是 Kubernetes 代理服务，主要功能包括向集群内部提供 Service 的 IP 地址及容器映射地址。
- kube-apiserver：kube-apiserver 是集群服务端口（k API）实例，在其上运行的进程监听并处理来自客户端的 HTTP 请求。
- etcd：etcd 是 Kubernetes 数据存储系统，在其存储路径下维护着集群内所有核心对象信息（如Pod、Service和复制控制器等）。
- kube-scheduler：kube-scheduler 是 Kubernetes 节点调度器，在执行资源调度算法之前会根据当前负载状况将 Pod 分配至合适的工作节点上运行。
以上组件基本涵盖了Kubernetes的核心功能，还有一些常用组件还有：
- kube-dns：kube-dns 是 Kubernetes 集群中的一个 DNS 插件，在集群内部实现服务发现功能。
- Heapster：Heapster 是 Kubernetes 环境中独立部署的一个性能数据采集与展示工具。
- Ingress Controller：Ingress Controller 作为 Kubernetes 组件，在集群流量管理方面承担路由 HTTP 和 HTTPS 请求的任务。
- Dashboard：Dashboard 提供用于管理和监控 Kubernetes 集群功能的 Web 型用户界面。
3.核心算法原理和具体操作步骤以及数学公式讲解
3.1 创建POD
创建一个名叫"web"的pod，运行nginx的容器：
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
protocol: TCP
代码解读在配置文件中，通过YAML格式描述了一个Pod named "web"。该Pod包含一个容器名为"nginx"，其镜像使用的是nginx:latest版本。值得注意的是，在该Pod的配置中仅开放了TCP协议下的端口80，并且外部用户无法直接进行访问。
另外，我们也可以使用命令行工具kubectl create 来创建pod：
$ kubectl create -f pod.yaml
代码解读这样可以直接创建这个"web" pod。当然地讲，在试图采用声明式的办法建立pod时，请注意：你可以利用配置文件来定义pod的相关属性，并且无需编写yaml文件。
3.2 查看POD列表
查看当前集群中所有的pods：
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
web 1/1 Running 0 5m
代码解读使用-A选项可以查看所有命名空间下的pods：
$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
default web 1/1 Running 0 5m
kube-system coredns-5c98d7d4d8-lpdvx 1/1 Running 0 3h
kube-system coredns-5c98d7d4d8-vlvnm 1/1 Running 0 3h
kube-system etcd-minikube 1/1 Running 0 3h
kube-system kube-addon-manager-minikube 1/1 Running 0 3h
kube-system kube-apiserver-minikube 1/1 Running 0 3h
kube-system kube-controller-manager-minikube 1/1 Running 0 3h
kube-system kube-proxy-b78f7 1/1 Running 0 3h
kube-system kube-scheduler-minikube 1/1 Running 0 3h
kube-system storage-provisioner 1/1 Running 0 3h
代码解读3.3 删除POD
删除名叫"web"的pod：
$ kubectl delete pod web
pod "web" deleted
代码解读-n <namespace>选项可以指定删除某个命名空间下的pod：
$ kubectl delete pod web -n default
pod "web" deleted
代码解读3.4 查看POD详细信息
查看名叫"web"的pod的详细信息：
$ kubectl describe pod web
Name: web
Namespace: default
Priority: 0
PriorityClassName: <none>
Node: minikube/192.168.99.100
Start Time: Sat, 06 Jun 2019 11:12:08 +0800
Labels: <none>
Annotations: <none>
Status: Running
IP: 172.17.0.2
Controlled By: ReplicaSet/web
Containers:
nginx:
Container ID: docker://a0fbcf79ddff844c87fc0171ecfc35fd9c9c38bced4b69e7cbaa787620bf5e3a
Image: nginx:latest
Image ID: docker-pullable://nginx@sha256:dbdc38b1b5faea85e6b6cccf60fe8d2e0be3d2abca7dfce705679a6f703c9dc0
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Sat, 06 Jun 2019 11:12:10 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-zkzmk (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-zkzmk:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-zkzmk
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 5m default-scheduler Successfully assigned web to minikube
Normal SuccessfulMountVolume 5m kubelet, minikube MountVolume.SetUp succeeded for volume "default-token-zkzmk"
Normal Pulled 4m (x4 over 5m) kubelet, minikube Container image "nginx:latest" already present on machine
Normal Created 4m (x4 over 5m) kubelet, minikube Created container
Normal Started 4m (x4 over 5m) kubelet, minikube Started container
Warning Unhealthy 2m (x7 over 4m) kubelet, minikube Readiness probe failed: Get http://172.17.0.2:80/: dial tcp 172.17.0.2:80: connect: connection refused
Normal Killing 2m (x2 over 4m) kubelet, minikube Container nginx failed liveness probe, will be restarted
Normal Pulled 2m (x3 over 3m) kubelet, minikube Container image "k8s.gcr.io/etcd:3.2.24" already present on machine
Normal Created 2m (x3 over 3m) kubelet, minikube Created container
Normal Started 2m (x3 over 3m) kubelet, minikube Started container
Normal Pulling 2m (x2 over 3m) kubelet, minikube pulling image "gcr.io/google_containers/pause-amd64:3.0"
Normal Pulled 2m (x2 over 3m) kubelet, minikube Successfully pulled image "gcr.io/google_containers/pause-amd64:3.0"
Normal Created 2m (x2 over 3m) kubelet, minikube Created container
Normal Started 2m (x2 over 3m) kubelet, minikube Started container
Warning BackOff 1m (x3 over 2m) kubelet, minikube Back-off restarting failed container
Normal Pulled 1m (x2 over 2m) kubelet, minikube Container image "k8s.gcr.io/kube-proxy:v1.15.0" already present on machine
Normal Created 1m (x2 over 2m) kubelet, minikube Created container
Normal Started 1m (x2 over 2m) kubelet, minikube Started container
Warning FailedSync 1m (x2 over 2m) kubelet, minikube Error syncing pod
代码解读-n <namespace>选项可以指定查看某个命名空间下的pod：
$ kubectl describe pod web -n kube-system
Name: kube-proxy-b78f7
Namespace: kube-system
Priority: 2000001000
Priority Class Name: system-node-critical
Node: minikube/192.168.99.100
Start Time: Fri, 05 Jun 2019 17:38:59 +0800
Labels: k8s-app=kube-proxy
pod-template-hash=66bc5cb4f
Annotations: <none>
Status: Running
IP: 172.17.0.4
IPs:
IP: 172.17.0.4
Controlled By: DaemonSet/kube-proxy
Containers:
kube-proxy:
Container ID: docker://e3d57b862f25bb8f1b8d84d81b3d4b13cbcf25da8f1e9761c7a3b30dbcfba67d
Image: gcr.io/google_containers/hyperkube-amd64:v1.12.0
Image ID: docker-pullable://k8s.gcr.io/hyperkube-amd64@sha256:e17f934ae8571d604de221598156052b6c69af9a32b5f8b84a3319a56c53f7ad
Command:
/usr/local/bin/kube-proxy
--config=/var/lib/kube-proxy/config.conf
--hostname-override=$(NODE_NAME)
State: Running
Started: Fri, 05 Jun 2019 17:39:05 +0800
Last State: Terminated
Reason: Completed
Exit Code: 0
Started At: Fri, 05 Jun 2019 17:38:57 +0800
Finished At: Fri, 05 Jun 2019 17:39:04 +0800
Ready: True
Restart Count: 0
Requests:
cpu: 100m
memory: 20Mi
Liveness: http-get https://localhost:10256/healthz delay=15s timeout=15s period=10s #success=1 #failure=3
Environment: <none>
Mounts:
/etc/ssl/certs from ssl-certs-host (ro)
/etc/sysconfig/kube-proxy from kube-proxy-config (rw)
/usr/local/share/ca-certificates from ca-certs (ro)
/var/lib/kube-proxy from kube-proxy (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube-proxy-token-6pksm (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-proxy:
Type: EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
kube-proxy-config:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: kube-proxy
Optional: false
ssl-certs-host:
Type: HostPath (bare host directory volume)
Path: /usr/share/ca-certificates
HostPathType: DirectoryOrCreate
ca-certs:
Type: HostPath (bare host directory volume)
Path: /etc/ssl/certs
HostPathType:
QoS Class: Burstable
Node-Selectors: beta.kubernetes.io/os=linux
Tolerations: :NoSchedule op=Exists
taints=[node-role.kubernetes.io/master]
Events: <none>
代码解读3.5 使用YAML模板创建POD
使用YAML模板创建POD：
apiVersion: v1
kind: Pod
metadata:
labels:
app: myapp
name: myapp-pod
namespace: devops
spec:
containers:
- env:
- name: MYSQL_HOST
value: mysql-server
image: busybox
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
restartPolicy: Never
代码解读上面的yaml文件包含三个部分：
- metadata：用于记录 pod 的名称及其 associated 标签。
- spec：定义 pod 的配置参数。
- container：指定 pod 的运行环境与资源设置。
3.6 更新POD
如果需要对正在运行中的 pod 进行修改，则可采用 kubectl edit 命令来编辑 pod 的配置文件；亦可直接在配置文件中进行重新应用操作即可完成修改任务。修改完成后系统会自动将更新的内容应用至对应的 pod 上方程组号方程组号方程组号方程组号方程组号方程组号方程组号方程组号）。例如：假设有现有一个正在运行中的 pod 命名为 "web" 现在希望新增一个环境变量 NEW_ENV 其值为 test 则可采取以下两种方式实现：
- 使用
kubectl edit命令编辑pod的配置文件：
$ kubectl edit pod web
apiVersion: v1
kind: Pod
...
---
apiVersion: v1
data:
NEW_ENV: test
kind: ConfigMap
metadata:
creationTimestamp: null
name: newenv
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
env:
- name: NEW_ENV
valueFrom:
configMapKeyRef:
key: NEW_ENV
name: newenv
status: {}
代码解读在web的pod配置的最后增加了一个新环境变量的ConfigMap。
- 通过配置文件重新apply一下pod：
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
containers:
- name: nginx
image: nginx:latest
env:
- name: NEW_ENV
valueFrom:
configMapKeyRef:
key: NEW_ENV
name: newenv
代码解读用以下命令创建配置文件，并通过kubectl apply命令创建相应的pod：
$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
containers:
- name: nginx
image: nginx:latest
env:
- name: NEW_ENV
valueFrom:
configMapKeyRef:
key: NEW_ENV
name: newenv
EOF
代码解读3.7 访问POD
一旦pod的容器启动成功后，则可以通过localhost或者确定其所在节点IP地址并附加相应端口号的方式接入该容器
$ curl localhost:80
Hello Kubernetes!
代码解读改写说明
$ kubectl port-forward web 8080:80
Forwarding from 127.0.0.1:8080 -> 80
Handling connection for 8080
Handling connection for 8080
Handling connection for 8080
^C^C[1]+ Stopped kubectl port-forward web 8080:80
代码解读这样就可以通过浏览器或者curl访问http://localhost:8080。
3.8 排查POD问题
当POD出现错误时，可以通过以下命令查看相关信息：
$ kubectl logs <POD_NAME>
代码解读该命令可输出容器日志信息；若某容器长时间维持'Waiting'态或经历'CrashLoopBackOff'态，则可借助这些指令诊断其问题根源。
$ kubectl describe pod <POD_NAME>
代码解读该命令将生成Pod的详细信息（包括事件、容器状态及重启次数等）。当Pod进入CrashLoopBackOff状态时，原因可能多种多样。
- 配置错误：容器启动失败可能源于缺少必要的镜像文件、运行参数以及环境变量设置等关键要素；
- 资源不足：例如容器运行过程中遇到的CPU和内存不足问题。
- 端口冲突：其中前面的容器已经占据了相同端口号码而导致当前容器无法正常启动。
可以通过kubectl exec命令进入pod内部，分析错误原因：
$ kubectl exec -it <POD_NAME> sh
代码解读进入pod内部之后，可以运行诊断命令分析问题：
# 查看容器进程信息
ps aux
# 检查文件权限
ls -l /path
# 查看系统日志
cat /var/log/*
代码解读3.9 POD的生命周期
由两个阶段构成的一个Pod的生命历程依次经历着不同的状态转变
3.9.1 创建POD
当我们在Kubernetes集群中提交一个Pod配置文件时, Kubernetes Master会验证所有Pod的语法规范, 进而利用相应的调度机制来处理每个 Pod. 例如, 在调度过程中, Deployment controller会根据预设策略将Pod分配至最合适的Node上.
在 Kubernetes 管理系统中，在控制器完成将 Pod 部署至目标 Node 的操作后，在 Kubernetes 中会有相应的机制确保该 Pod 被正确调度。随后, kubelet 会从存储系统中获取该 Pod 所需的所有镜像副本；接着, 根据 Pod 的配置文件信息, 容器将会被正确配置并投入运行。
当容器启动完成之后，Pod的状态会从Pending变成Running。
3.9.2 终止POD
当一个 Pod 处于非运行状态时，我们可以通过手动操作或借助相应的控制机制来终止该 Pod。
在用户移除一个 Pod 时，Kubernetes 会自动移除该 Pod 以及与其相关的容器，并同时触发与该节点上 Pod 相关联的清理控制程序。
当一个Pod被删除时,其状态将转为Terminating;kubelet将等待所有相关容器完成;随后才会彻底终止该Pod
4.具体代码实例和解释说明
下面让我们用一个例子来说明上述过程。
4.1 演示案例：部署NGINX
在我们的环境中，我们需要设置一台NGINX以便让它能够被外部访问。为了实现这一目标，我们可以采用端口映射的方式连接该服务器至外网。此外，在当前的配置中，我们的服务器集合仅包含一个节点。
首先，我们需要创建一个配置文件来定义这个NGINX的Pod：
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
protocol: TCP
代码解读然后，通过如下命令创建这个Pod：
$ kubectl apply -f nginx.yaml
pod/nginx created
代码解读接着，可以使用如下命令查看刚才创建的NGINX的状态：
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 3m
代码解读观察到NGINX的状态显示为Running状态，并且READY列的数值为1/1。这表明该NGINX服务只有一个容器已经就绪并准备好接收请求。
通过以下方式实现：使用port-forward命令，在本机计算机上打开80端口，并将其流量转发至NGINX服务器上的相应80端口位置。
$ kubectl port-forward nginx 8080:80
Forwarding from 127.0.0.1:8080 -> 80
Handling connection for 8080
Handling connection for 8080
Handling connection for 8080
代码解读可以看到，已经成功将本地计算机的8080端口转发到了NGINX的80端口。
当前在本机电脑的浏览器端访问地址http://localhost:8080/即可连接到刚才部署的Nginx服务。
至此，我们已经成功地部署了NGINX。
5.未来发展趋势与挑战
随着container技术的发展速度越来越快, kubernetes迅速崛起并被广泛认为是行业内的标准选择。作为想入门kubernetes学习者来说,核心概念和基本操作技巧作为入门必修内容同样不可或缺。针对已经有一定kubernetes知识储备的学习者而言,掌握其他组件以及高级特性同样需要深入理解和熟练运用。
尽管Kubernetes具备广泛的功能和特性但仍然面临着诸多挑战尤其是扩展性方面的难题这一最突出的问题已困扰该系统多年
另一个主要问题是 Kubernetes 系统在弹性伸缩方面的挑战。通常情况下，默认配置下的集群规模相对较小。当集群规模扩大后，仅凭人工手动进行微调可能会导致较高的维护代价。为了进一步提升系统性能，Kubernetes 项目将继续探索更为高效的伸缩管理策略。
6.常见问题与解答
Q: Kubernetes有哪些组件？这些组件又分别有什么作用？
A: Kubernetes 有四个主要的组件：
- Kubelet是运行在每个Node上的角色。它主要负责管理容器和Pod的生命历程。
- Kube-Proxy充当着Kubernetes服务与外部系统的接口角色。它的主要职责是实现集群成员间的通信枢纽。
- Kubernetes API Server作为整个系统的中枢节点。它不仅指挥各个节点调度资源和任务，并且还承担着集群状态监控与管理的重要职责。
- Etcd是一种分布式键值存储系统。它的主要功能是保障Kubernetes集群中各组件之间的数据一致性与可扩展性。
除了这些之外，另外还有若干组件与功能。如日志收集与查询功能、监控系统以及网络相关插件等。
Q: 为什么要使用 Kubernetes？
在过去的几年中，容器技术实现了快速进步，在线Kubernetes解决方案已经成为了容器编排领域的不可动摇的事实标准。原因在于其采用了一种简单、可靠且可扩展的方式来进行集群管理。
通过使用 Kubernetes，你可以：
- 采用微服务架构进行应用的配置与维护而非依赖虚拟机架构。
- 通过水平可扩展性实现应用运行的同时无需关注底层基础设施。
- 更加简便地完成应用的部署与维护得益于Kubernetes对部署扩展与管理的自动化处理。
- 确保可靠运行的应用环境。
- Kubernetes集群内置统一的日志收集与监控功能此功能便于开发者与运维团队快速定位并解决相关问题。