1.kubelet 远程调试方法
2.Kubernetes(k8s)-v1.22.3版本证书有效期修改
3.kubelet版本升级引起的容器重启机制与参考解决方案
4.一次“不负责任”的 K8s 网络故障排查经验分享
5.什么是K8S？
6.详解边缘计算系统逻辑架构：云、边、端协同
kubelet 远程调试方法
Kubelet远程调试方法详解
Kubelet作为Kubernetes的核心组件，可以通过系统服务管理和编译工具进行远程调试。首先，理解kubelet的分段指标源码启动命令至关重要。在v1..4的K8s集群中，kubelet作为systemd服务，其配置文件位于</etc/systemd/system/kubelet.service.d/-kubeadm.conf>。通过执行ps -ef | grep /usr/bin/kubelet，可以查看完整的启动命令。 若需修改kubelet命令，可以先停止服务，然后使用相应参数重新启动，或者修改systemd配置后重启服务。编译kubelet时，推荐使用Kubernetes makefile源码中的编译指令，调整GOLDFLAGS和GOGCFLAGS以保留调试信息。编译完成后，kubelet二进制文件会位于_output/bin/kubelet。 对于Go语言的调试，Delve是一个高效工具，尤其适合调试标准工具链构建的Go程序。可以通过安装命令轻松获取，并使用它来调试kubelet。例如，使用dlv命令行进行调试步骤包括设置地址和端口，以及在GoLand IDE中配置并启动kubelet进行调试。 除了Kubelet，其他容器软件如runc和docker-cli也可通过修改编译命令进行调试。例如，runc和dockerd的编译过程中，需要在scripts/build/binary或hack/make/.binary文件中相应位置调整编译参数。 获取更多详细教程和实践步骤，可以参考ssst0n3.github.io/post/...。通过以上步骤，你可以有效地对kubelet和其他容器软件进行远程调试，提升开发效率。Kubernetes(k8s)-v1..3版本证书有效期修改
在长时间使用Kubernetes（K8s）后，您可能会发现SSL证书一年有效期的限制。为解决这一问题，本教程将指导您如何修改Kubernetes v1..3版本中证书的有效期。
在开始之前，peach源码下载确保您的系统环境包括以下组件：CentOS Linux release 7.7. (Core) 5.4.-1.el7.elrepo.x_，kubeadm-1..3-0.x_，kubelet-1..3-0.x_，kubectl-1..3-0.x_，以及kubernetes-cni-0.8.7-0.x_。
### 查看证书有效期
通过两种方法检查证书有效期：
1. 第一种方法：显示当前证书有效期。
2. 第二种方法：同样显示当前证书有效期。
请注意，如果证书已更新，则显示的日期将不同。但与第一种方法的结果一致，通常为一年。
### 修改证书有效期步骤
#### 准备环境
1. 访问Go语言中文网下载最新版本的Go环境。
2. 在Linux系统中配置环境变量。
3. 验证Go环境已正确安装。
#### 下载Kubernetes源码
1. 查看当前系统版本以下载与之匹配的Kubernetes v1..3源码。
2. 确保能访问外网以从GitHub下载源码。
3. 下载源码并解压。
#### 修改源代码文件
1. 修改两个关键文件：`constants.go` 和 `cert.go`。
2. 通过`vim`查找`CertificateValidity`字段。
3. 修改`cert.go`文件中的相关代码。
4. 编译修改后的源代码文件。
5. 生成新的Kubeadm二进制文件。
6. 备份旧的Kubeadm文件，确保三台master节点均备份。
7. 替换新文件。
#### 更新证书
1. 执行证书更新命令。
2. 观察结果，了解需要重启哪些服务以使更新生效。
3. 重启这台master服务器。
4. 查看新证书，除CA外，所有证书有效期更新为年，未修改`cert.go`文件。
5. 同样步骤更新其他两台master节点，将更新过的Kubeadm文件通过scp传输，并根据上述步骤生成新的证书文件。记得在更新后重启服务或服务器。
kubelet版本升级引起的容器重启机制与参考解决方案
kubelet版本升级与容器自动重启关联问题解析与解决方案
背景
kubernetes能够提供服务高可用性，其副本机制确保了实例副本数量，当某个实例异常时，服务可以被自动恢复。源码资本广州然而，在生产环境中，某些关键服务（如广告资金服务或计费服务）在容器重启期间可能会导致业务中断，延迟响应请求也是不可忽视的问题。在kubelet版本升级时，已经运行的容器服务可能会因升级而自动重启，这在特殊生产环境中需要尽量避免。
问题分析
kubelet升级后，容器自动重启的主要原因是kubelet启动后的接口函数调用链中的一个关键判断逻辑。这一逻辑决定容器服务是否重启。通过分析整个调用链关系图，可以追踪到重启的根本原因。关键逻辑主要在kubelet启动后的`computePodActions()`函数中的`containerChanged()`函数。该函数通过比较容器结构元素的HASH值来判断容器是否发生变化，进而决定是否重启。
原因解析
kubelet升级后，不同版本的容器结构可能包含额外的成员，如`VolumeDevices`等。这些新增成员导致在进行HASH计算时，升级前后的HASH值不一致，从而触发容器的重启。
解决方案
为了避免容器因版本升级而自动重启，可以记录并持久化kubelet版本信息与启动时间。在计算容器结构的HASH值时，参考持久化信息来判断是否忽略重启操作。通过修改源代码，实现这一方案，代码示例可参考GitHub上的补丁文件。
适用场景及注意事项
此方案适用于在kubelet版本升级情况下，希望容器服务持续运行不重启的业务场景。但在实现中需要注意以下几点：
1. 在版本升级前，需对比不同版本容器结构的变化，了解版本升级对容器HASH计算的影响。
2. 采用记录并缓存kubelet版本及启动时间至本地文件的方法，可能因文件损坏导致容器服务仍重启。可临时手动生成文件作为备份。
3. 每次版本升级前需更新源码并重新编译生成二进制文件，这一过程较为繁琐。
总结
通过解析自kubelet启动至容器服务重启的调用链路，确认了版本升级后引起容器重启的判断条件及处理逻辑。同时，提供了解决方案以避免容器因版本升级而重启，多玩论坛源码这一方法有助于解决生产环境中关键业务无服务中断的问题。尽管存在一些注意事项，但通过代码修改和适当的规划，可以实现稳定、高效的容器服务运行。
一次“不负责任”的 K8s 网络故障排查经验分享
一次K8s网络故障排查的实战分享 作者骆冰利在处理一起客户K8s集群扩容失败问题时，揭示了深入排查的整个过程。客户使用的是1..版本的Kubernetes，宿主机内核为4.（CentOS 8.2），遇到节点无法加入集群的问题。故障现象表现为新节点无法通过master service VIP访问，但直接访问master hostIP则正常。以下是排查的关键步骤： 首先，常规排查显示iptables模块加载正常，iptables转发规则默认接受，宿主机和容器网络都正常。接着，通过ipvsadm发现kube-proxy在启动后存在异常连接，syn_recv状态，表明K8s service网络出现问题。 进一步分析，通过tcpdump抓包发现SYN包未从本地发送，初步锁定问题在kube-proxy。查看kube-proxy日志后，发现与iptables-restore命令的执行异常有关，涉及到KUBE-MARK-DROP链的创建问题。深入源码后，发现1..版本在特定条件下存在逻辑缺陷，导致报错。 问题的根源在于，CentOS 8.2的4.内核环境下的iptables配置与kube-proxy容器内的配置不一致，因为Kubernetes的kubelet也在操作iptables。解决办法是升级内核至3.或5.0+，或者更新Kubernetes版本至1..以上。 总结这次经验，对于K8s网络故障，关键在于理解内核、kube-proxy、kubelet之间的交互，以及选用正确的工具，如iptables或nftables。希望这个案例能帮助其他开发者在遇到类似问题时能更快定位和解决。epower 源码下载 如果想了解更多Erda项目信息，可以添加小助手微信（Erda）加入交流群。Erda是一个开源的云原生PaaS平台，欢迎关注、贡献代码和Star支持。 Erda Github 地址 | Erda Cloud - 企业级数字平台什么是K8S？
k8s是什么?Kubernetes 是一个可移植的，可扩展的开源容器编排平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务，支持和工具广泛可用。
为什么现在流行使用容器?
早期: 在物理服务器上面部署应用程序存在资源分配问题,因为其不能在物理服务器中的应用程序定义资源边界,导致应用程序资源利用不足而无法扩展.
后来: 为了解决该问题,引入了虚拟化技术, 虚拟化技术是指允许你在单个物理服务器的 CPU 上运行多个虚拟机,可以让多个应用程序在虚拟机之间进行隔离,具有一定的安全性, 每一个虚拟机就是一台完整的计算机, 在虚拟化硬件之上运行所有组件.
现在: 多数在物理服务器上面部署应用程序都是采kubectl用容器的方式,容器类似于虚拟机,它们都具有自己的文件系统、CPU、内存、进程空间等, 且由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。基于此特点被企业大范围使用.
为什么需要使用k8s容器?
若出现这样一个环境: 在生产环境中如果一个容器发生故障,则我们需要手动去启动另外一个容器,这样的操作是对我们的管理员来说是不太方便的, 若一个容器出现故障,另一个容器可以自动启动容器接管故障的容器,这样是最好的.
k8s就可以实现该效果,Kubernetes 提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。
k8s功能: 服务发现和负载均衡, 存储编排, 自动部署和回滚, 自动完成装箱计算, 自我修复, 密钥与配置管理
名词解释
secret
Secret有三种类型：
Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的目录中；/run/secrets/kubernetes.io/serviceaccountOpaque：base编码格式的Secret，用来存储密码、密钥等；kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。k8s的组成
k8s是由组件,API,对象等组成.
包含所有相互关联组件的 Kubernetes 集群图如下:
组件
控制平面组件kube-apiserver: 为k8s的api服务器,公开了所有Kubernetes API, 其他所有组件都必须通过它提供的API来操作资源数据.保证集群状态访问的安全隔离集群状态访问的方式和后端存储实现的方式：API Server是状态访问的方式，不会因为后端存储技术etcd的改变而改变。etcd: 为k8s的键值数据库,保存了k8s所有集群数据的后台数据库。kube-scheduler: 收集和分析当前Kubernetes集群中所有Node节点的资源(内存、CPU)负载情况，然后依此分发新建的Pod到Kubernetes集群中可用的节点。 kube-controller-manager: 在主节点上运行 控制器 的组件。cloud-controller-manager: 云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件Node 组件kubelet: 一个在集群中每个节点（node）上运行的代理。 它保证容器（containers）都 运行在 Pod 中。kube-proxy: kube-proxy是集群中每个节点上运行的网络代理,维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。容器运行时: 负责运行容器的软件。插件(Addons)DNS: 集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。Web 界面（仪表盘）: Dashboard 是Kubernetes 集群的通用的、基于 Web 的用户界面。容器资源监控: 容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。集群层面日志: 集群层面日志 机制负责将容器的日志数据 保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。 APIKubernetes 控制面 的核心是 API 服务器。 API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。
对象
Kubernetes对象是Kubernetes系统中的持久实体。Kubernetes使用这些实体来表示集群的状态.
具体来说，他们可以描述：
容器化应用正在运行(以及在哪些节点上)这些应用可用的资源关于这些应用如何运行的策略，如重新策略，升级和容错Kubernetes 架构
Kubernetes 架构由节点,控制面到节点通信, 控制器, 云控制器管理器组成.
master 流程图
Kubecfg将特定的请求，比如创建Pod，发送给Kubernetes Client。Kubernetes Client将请求发送给API server。API Server根据请求的类型，比如创建Pod时storage类型是pods，然后依此选择何种REST Storage API对请求作出处理。REST Storage API对的请求作相应的处理。将处理的结果存入高可用键值存储系统Etcd中。在API Server响应Kubecfg的请求后，Scheduler会根据Kubernetes Client获取集群中运行Pod及Minion/Node信息。依据从Kubernetes Client获取的信息，Scheduler将未分发的Pod分发到可用的Minion/Node节点上。 节点节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 每个节点包含运行 Pods 所需的服务， 这些 Pods 由 控制面 负责管理.
节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。
节点状态
可以使用 kubectl 来查看节点状态和其他细节信息：
kubectl describe node <�节点名称>
一个节点包含以下信息:
地址HostName：由节点的内核设置。可以通过 kubelet 的 —hostname-override 参数覆盖。ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。状况(conditions 字段描述了所有 Running 节点的状态)Ready 如节点是健康的并已经准备好接收 Pod 则为 True；False 表示节点不健康而且不能接收 Pod；Unknown 表示节点控制器在最近 node-monitor-grace-period 期间（默认 秒）没有收到节点的消息DiskPressure为True则表示节点的空闲空间不足以用于添加新 Pod, 否则为 FalseMemoryPressure为True则表示节点存在内存压力，即节点内存可用量低，否则为 FalsePIDPressure为True则表示节点存在进程压力，即节点上进程过多；否则为 FalseNetworkUnavailable为True则表示节点网络配置不正确；否则为 False容量与可分配描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。信息关于节点的一般性信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、 Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。控制面到节点通信
节点到控制面apiserver在安全的 HTTPS 端口（）上监听远程连接请求以客户端证书的形式将客户端凭据提供给 kubelet控制面到节点API 服务器到 kubelet连接用于获取 Pod 日志挂接（通过 kubectl）到运行中的 Pod提供 kubelet 的端口转发功能。(注: 在连接状态下, 默认apiserver 不检查 kubelet 的服务证书。容易受到中间人攻击，不安全.)apiserver 到节点、Pod 和服务SSH 隧道(目前已经废弃)产生原因: 若无服务证书, 又要求避免在非受信网络或公共网络上进行连接,则可以在apiserver 和 kubelet 之间使用ssh隧道.Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。Konnectivity 服务为ssh隧道的替代品, Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。控制器
在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。
举个例子: 当前室内温度为度, 我们通过调节遥控器,使其温度上升至度, 这度到度的变化即为让其从当前状态接近期望状态。
控制器模式分为直接控制和通过API服务器来控制.
云控制器管理器
云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接聚合到云提供商的应用编程接口中， 并分离出相互作用的组件与您的集群交互的组件。
云控制器管理器中的控制器包括：
节点控制器节点控制器负责在云基础设施中创建了新服务器时为之 创建 节点（Node）对象。 节点控制器从云提供商获取当前租户中主机的信息。执行功能:针对控制器通过云平台驱动的 API 所发现的每个服务器初始化一个 Node 对象利用特定云平台的信息为 Node 对象添加注解和标签获取节点的网络地址和主机名检查节点的健康状况。路由控制器Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的 容器之间可以相互通信。服务控制器服务（Service）与受控的负载均衡器、 IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。 服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。Kubernetes 安全性
云原生安全
云原生安全4个C: 云(Cloud)、集群(Cluster)、容器(Container)和代码(Code)
云原生安全模型的每一层都是基于下一个最外层，代码层受益于强大的基础安全层（云、集群、容器）。我们无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。
基础设施安全
Kubetnetes 基础架构关注领域
建议
通过网络访问 API 服务（控制平面)
所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开，同时应由网络访问控制列表控制，该列表包含管理集群所需的 IP 地址集。
通过网络访问 Node（节点)
节点应配置为 仅能 从控制平面上通过指定端口来接受（通过网络访问控制列表）连接，以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话，这些节点不应完全暴露在公共互联网上。
Kubernetes 云访问提供商的 API
每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时，最好遵循对需要管理的资源的最小特权原则。Kops 文档提供有关 IAM 策略和角色的信息。
访问 etcd
对 etcd（Kubernetes 的数据存储）的访问应仅限于控制平面。根据配置情况，你应该尝试通过 TLS 来使用 etcd。更多信息可以在 etcd 文档中找到。
etcd 加密
在所有可能的情况下，最好对所有驱动器进行静态数据加密，但是由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。
集群组件安全
运行的应用程序的安全性关注领域访问控制授权(访问 Kubernetes API)认证方式应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密)Pod 安全策略服务质量（和集群资源管理）网络策略Kubernetes Ingress 的 TLS 支持容器安全
容器安全性关注领域容器搭建配置(配置不当,危险挂载, 特权用户)容器服务自身缺陷Linux内核漏洞镜像签名和执行代码安全
代码安全关注领域仅通过 TLS 访问(流量加密)限制通信端口范围第三方依赖性安全静态代码分析动态探测攻击(黑盒)Kubernetes架构常见问题
Kubernetes ATTACK 矩阵
信息泄露
云账号AK泄露
API凭证（即阿里云AccessKey）是用户访问内部资源最重要的身份凭证。用户调用API时的通信加密和身份认证会使用API凭证.
API凭证是云上用户调用云服务API、访问云上资源的唯一身份凭证。
API凭证相当于登录密码，用于程序方式调用云服务API.
k8s configfile泄露
kubeconfig文件所在的位置:
$HOME/.kube/config
Kubeconfig文件包含有关Kubernetes集群的详细信息，包括它们的位置和凭据。
云厂商会给用户提供该文件,以便于用户可以通过kubectl对集群进行管理. 如果攻击者能够访问到此文件（如办公网员工机器入侵、泄露到Github的代码等），就可以直接通过API Server接管K8s集群，带来风险隐患。
Master节点SSH登录泄露
常见的容器集群管理方式是通过登录Master节点或运维跳板机，然后再通过kubectl命令工具来控制k8s。
云服务器提供了通过ssh登陆的形式进行登陆master节点.
若Master节点SSH连接地址泄露,攻击者可对ssh登陆进行爆破,从而登陆上ssh,控制集群.
容器组件未鉴权服务
Kubernetes架构下常见的开放服务指纹如下:
kube-apiserver: , kubectl proxy: , kubelet: , , dashboard: docker api: etcd: , kube-controller-manager: kube-proxy: , kube-scheduler: weave: , , kubeflow-dashboard:注:前六个重点关注: 一旦被控制可以直接获取相应容器、相应节点、集群权限的服务
了解各个组件被攻击时所造成的影响
组件分工图:
假如用户想在集群里面新建一个容器集合单元, 流程如下:
用户与 kubectl进行交互,提出需求(例: kubectl create -f pod.yaml)kubectl 会读取 ~/.kube/config 配置，并与 apiserver 进行交互，协议：/service-account/cloud-native-academy/cloud-native-applications/cloud-native-infrastructure/
es控制节点与KubeEdge相连接，两者协同运行。Kubernetes在管理普通节点的同时，也可以管理KubeEdge节点。KubeEdge运行在边缘节点上，通过云部分的CloudCore和边缘部分的EdgeCore，实现了Kubernetes云计算编排容器化应用的下沉。CloudCore负责监听控制节点指令，EdgeCore执行指令并汇报状态信息。
EdgeCore在Kubelet基础上定制而成，针对边缘节点资源限制和网络质量不佳的情况，增加了离线计算功能，使其适应边缘环境。
边、端协同
边、端协同通过MQTT代理和对接支持多种协议设备的服务实现。KubeEdge端解决方案虽然较为初级，但我们的系统使用了功能更为完善的IoT SaaS平台EdgeX Foundry。
云、边、端协同
云、边、端协同的理想状态包括云、边协同和云、边、端协同两个层面。通过Kubernetes控制节点、KubeEdge和EdgeX Foundry协同操作，实现对终端设备的影响。但目前，控制节点与终端设备的直接交互还有待改进。
结论
本文系统梳理了边缘计算系统的逻辑架构和云、边、端之间的逻辑关系与现状。通过深入理解边缘计算系统的运行原理与源码分析，可以更好地构建协同的云、边、端系统。
kubelet 启动流程分析
kubernetes版本：v1.
kubelet启动流程从其main函数开始，调用NewKubeletCommand方法获取配置参数并校验，为参数设置默认值。
Run方法仅调用run方法执行后续启动逻辑，run方法为kubelet启动配置及检查工作，主要逻辑涉及基本配置和检查。
RunKubelet调用createAndInitKubelet方法，完成kubelet组件初始化，随后调用startKubelet启动组件。
createAndInitKubelet方法调用三个方法实现kubelet初始化，NewMainKubelet方法初始化kubelet依赖模块，每个模块功能在前文“kubelet架构浅析”中介绍过。
startKubelet通过调用k.Run启动kubelet所有模块和主流程，启动http服务器，v1.默认启动健康检查端口和kubelet服务器端口。
Run方法启动核心逻辑，启动依赖模块及主循环，主要逻辑在下文中解释，调用关系总结于此。
Run方法调用kl.initializeModules和kl.fastStatusUpdateOnce完成启动前初始化，初始化完模块后启动主循环。
initializeModules启动不依赖容器运行时且不依赖初始化模块的模块，主要逻辑在此。
fastStatusUpdateOnce尝试更新podCIDR，一旦成功立即执行updateRuntimeUp和syncNodeStatus进行运行时更新和节点状态更新，仅在kubelet首次启动时执行一次，减少节点达到ready状态的时延。
updateRuntimeUp方法在容器运行时首次启动过程中初始化运行时依赖模块，更新容器运行时启动时间，检查网络和运行时是否处于ready状态，然后调用initializeRuntimeDependentModules初始化依赖模块。
initializeRuntimeDependentModules方法的逻辑在此。
小结：在Run方法中调用kl.syncNodeStatus和kl.updateRuntimeUp，但在fastStatusUpdateOnce中仅执行一次，目标是首次启动时快速进行运行时和节点状态更新。initializeRuntimeDependentModules方法通过sync.Once调用仅执行一次。
syncLoop是kubelet主循环方法，监听不同管道监听pod变化，将它们汇聚起来，当有新变化时调用对应函数保证pod处于期望状态。
syncLoop定义了syncTicker和housekeepingTicker，即使没有需要更新的pod配置，kubelet也会定时进行同步和清理pod工作。for循环中调用syncLoopIteration，每次循环中出现错误时记录到runtimeState中，遇到错误等待5秒继续循环。
syncLoopIteration方法监听多个channel，发现任何一个channel有数据交由handler处理，在handler中通过dispatchWork分发任务。它从以下channel获取消息。
最后总结启动kubelet及其依赖模块在Run方法中的调用流程。
本文主要介绍kubelet启动流程，流程环节众多，包含大量模块，后续分享的kubelet源码文章将以Run方法启动的模块为主，逐一分析。
