image.png
逻辑上可分4大部分
- 控制面： 云原生托管，对用户透明。包括api server 、etcd进程、controller-manager进程、scheduler进程、cloud-controller-manager云控制器
- 系统进程：在集群中的node上跑的进程，包括containerd、kubelet
- 系统pod ： 在kube-system命名空间下的一组Pod， 区别于用户应用pod，包括kube-proxy （每node1个），CSI node （每node1个），CoreDNS （随机分布在node上）， ingress Controller （随机分布）
- 用户Pod
三层服务发现机制和网络通信
- SLB -> ingress Controller ：cloud-controller-manager从api server中拉取ingress Controller所在的pod ip，写入SLB内的后端服务列表。SLB负载均衡选择其中一个pod ip,按这个ip把数据包(mac写vpc交换机)，扔进vpc，交换机转发到宿主机node（交换机查路由表，这个pod ip绑定到某台 ECS（Node）的弹性网卡（ENI），按照node mac转发），然后经过宿主机内核路由到达target pod ;
- ingress Controller -> 应用pod ：ingress Controller( openresty + go controller)，从api server获得写了ingress规则的应用pod ip或者说service，ingress controller直连访问这些pod ；
-
应用pod -> 应用pod ： 有两种情况，
- 一般情况下，pod通过域名访问的时候，通过CoreDNS走域名解析，拿到cluster ip、然后在出站访问的时候通过iptables做ip转换、把service cluster ip换成对应的pod ip，然后访问对端pod；这里有一次负载均衡：kube-proxy负责维护iptables，由Linux内核的iptables/IPVS模块从ClusterIP对应的Pod IP中选取1个作为目标IP。
- 还一种情况是headless service，这种情况不走DNS解析-cluster ip - kube proxy随机选pod ip的路子，而是直接由CoreDNS返回所有service pod ip，由客户端自己做负载均衡。或者，服务发现由其他组件接管、比如nacos，客户端从nacos获取就绪pod ip进行负载均衡调用。
一般的开发人员需要做什么
- 开发应用，制作dockerfile， 构建和推镜像到仓库。
- 写配置文件 ，一堆yaml文件，通过kubectl apply或控制台提交YAML文件，API Server将其解析为标准的Kubernetes资源对象（Go结构体序列化后的JSON），持久化存储至etcd中。
配置文件说明
| 文件 | 说明 |
|---|---|
| configmap.yaml | 应用集群的配置信息，对应之前放在各应用application.yaml中的那堆东西 |
| ingress.yaml | 网关路由信息，要通过ingress开放出去给到前端的服务要配置在这。一般配置到服务Service 一级。 |
| namespace.yaml | pod命名空间，逻辑隔离空间（区分系统system/用户环境） |
| rbac.yaml | 定义接入api server的一个账号，用在deployment.yaml里 |
| secret.yaml | 配置文件中的敏感信息 |
| deployment.yaml | 定义该服务一组无状态 Pod 的部署策略（副本数、更新方式） |
| service.yaml | 定义了该服务一组具有相同标签（如 app: account）的 Pod 的稳定网络访问入口（提供固定 IP 和负载均衡） Service 是通过 Label Selector（标签选择器） 匹配一组同类的 Pod，给它们提供一个固定的 ClusterIP（虚拟 IP） 和 DNS 域名。 |
| statefulset.yaml | 特殊的deployment，有状态 |
