来自:stackpush | 责编:乐乐
链接:blog.csdn.net/huakai_sun/article/details/82378856
正文
一个目标:容器操作;两地三中心;四层服务发现;五种 Pod 共享资源;六个 CNI 常用插件;七层负载均衡;八种隔离维度;九个网络模型原则;十类 IP 地址;百级产品线;千级物理机;万级容器;相如无亿,k8s 有亿:亿级日服务人次。
一个目标:容器操作
Kubernetes(k8s)是自动化容器操作的开源平台。这些容器操作包括:部署、调度和节点集群间扩展。
具体功能:
自动化容器部署和复制。
实时弹性收缩容器规模。
容器编排成组,并提供容器间的负载均衡。
调度:容器在哪个机器上运行。
组成:
kubectl:客户端命令行工具,作为整个系统的操作入口。
kube-apiserver:以 REST API 服务形式提供接口,作为整个系统的控制入口。
kube-controller-manager:执行整个系统的后台任务,包括节点状态状况、Pod 个数、Pods 和Service 的关联等。
kube-scheduler:负责节点资源管理,接收来自 kube-apiserver 创建 Pods 任务,并分配到某个节点。
etcd:负责节点间的服务发现和配置共享。
kube-proxy:运行在每个计算节点上,负责 Pod 网络代理。定时从 etcd 获取到 service 信息来做相应的策略。
kubelet:运行在每个计算节点上,作为 agent,接收分配该节点的 Pods 任务及管理容器,周期性获取容器状态,反馈给 kube-apiserver。
DNS:一个可选的 DNS 服务,用于为每个 Service 对象创建 DNS 记录,这样所有的 Pod 就可以通过 DNS 访问服务了。
下面是 k8s 的架构拓扑图:
两地三中心
两地三中心包括本地生产中心、本地灾备中心、异地灾备中心。
两地三中心要解决的一个重要问题就是数据一致性问题。
k8s 使用 etcd 组件作为一个高可用、强一致性的服务发现存储仓库。用于配置共享和服务发现。
它作为一个受到 Zookeeper 和 doozer 启发而催生的项目。除了拥有他们的所有功能之外,还拥有以下 4 个特点:
简单:基于 HTTP+JSON 的 API 让你用 curl 命令就可以轻松使用。
安全:可选 SSL 客户认证机制。
快速:每个实例每秒支持一千次写操作。
可信:使用 Raft 算法充分实现了分布式。
四层服务发现
先一张图解释一下网络七层协议:
k8s 提供了两种方式进行服务发现:
环境变量:当创建一个 Pod 的时候,kubelet 会在该 Pod 中注入集群内所有 Service 的相关环境变量。需要注意的是,要想一个 Pod 中注入某个 Service 的环境变量,则必须 Service 要先比该 Pod 创建。这一点,几乎使得这种方式进行服务发现不可用。
比如,一个 ServiceName 为 redis-master 的 Service,对应的 ClusterIP:Port 为 10.0.0.11:6379,则对应的环境变量为:
DNS:可以通过 cluster add-on 的方式轻松的创建 KubeDNS 来对集群内的 Service 进行服务发现。
以上两种方式,一个是基于 TCP,DNS 基于 UDP,它们都是建立在四层协议之上。
五种 Pod 共享资源
Pod 是 k8s 最基本的操作单元,包含一个或多个紧密相关的容器。
一个 Pod 可以被一个容器化的环境看作应用层的“逻辑宿主机”;一个 Pod 中的多个容器应用通常是紧密耦合的,Pod 在 Node 上被创建、启动或者销毁;每个 Pod 里运行着一个特殊的被称之为 Volume 挂载卷,因此他们之间通信和数据交换更为高效。在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个 Pod 中。
同一个 Pod 里的容器之间仅需通过 localhost 就能互相通信。
一个 Pod 中的应用容器共享五种资源:
PID 命名空间:Pod 中的不同应用程序可以看到其他应用程序的进程 ID。
网络命名空间:Pod 中的多个容器能够访问同一个IP和端口范围。
IPC 命名空间:Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信。
UTS 命名空间:Pod 中的多个容器共享一个主机名。
Volumes(共享存储卷):Pod 中的各个容器可以访问在 Pod 级别定义的 Volumes。
Pod 的生命周期通过 Replication Controller 来管理;通过模板进行定义,然后分配到一个 Node 上运行,在 Pod 所包含容器运行结束后,Pod 结束。
Kubernetes 为 Pod 设计了一套独特的网络配置,包括为每个 Pod 分配一个IP地址,使用 Pod 名作为容器间通信的主机名等。在公众号顶级架构师回复“架构整洁”,获取惊喜礼包。
六个 CNI 常用插件
CNI(Container Network Interface)容器网络接口是 Linux 容器网络配置的一组标准和库,用户需要根据这些标准和库来开发自己的容器网络插件。CNI 只专注解决容器网络连接和容器销毁时的资源释放,提供一套框架。所以 CNI 可以支持大量不同的网络模式,并且容易实现。
下面用一张图表示六个 CNI 常用插件:
七层负载均衡
提负载均衡就不得不先提服务器之间的通信。
IDC(Internet Data Center)也可称数据中心、机房,用来放置服务器。IDC 网络是服务器间通信的桥梁。
上图里画了很多网络设备,它们都是干啥用的呢?
路由器、交换机、MGW/NAT 都是网络设备,按照性能、内外网划分不同的角色。
内网接入交换机:也称为 TOR(top of rack),是服务器接入网络的设备。每台内网接入交换机下联 40-48 台服务器,使用一个掩码为 /24 的网段作为服务器内网网段。
内网核心交换机:负责 IDC 内各内网接入交换机的流量转发及跨 IDC 流量转发。
MGW/NAT:MGW 即 LVS 用来做负载均衡,NAT 用于内网设备访问外网时做地址转换。
外网核心路由器:通过静态互联运营商或 BGP 互联美团统一外网平台。
先说说各层负载均衡:
二层负载均衡:基于 MAC 地址的二层负载均衡。
三层负载均衡:基于 IP 地址的负载均衡。
四层负载均衡:基于 IP+端口 的负载均衡。
七层负载均衡:基于 URL 等应用层信息的负载均衡。
这里用一张图来说说四层和七层负载均衡的区别:
上面四层服务发现讲的主要是 k8s 原生的 kube-proxy 方式。k8s 关于服务的暴露主要是