[博学谷学习记录]超强总结,用心分享|架构 容器编排 Kubernetes（K8S）

提示：学习笔记 欢迎指点

1、K8S基本架构

目前主流的集群资源管理与使用框架大多都是主从（Master/Worker）模式，即一个Master管理一堆Worker去执行任务，对使用者屏蔽集群中结点之前相互通信的复杂细节，可以使用户像操作单机一样去操控整个集群。

K8S也不例外，在K8S中由master负责集群中应用的调度、更新、扩缩容等操作。 K8S中的执行角色为Node，一个Node一般是一个虚拟机或物理机，它上面事先运行着 docker 服务和 kubelet 服务（ Kubernetes 的一个组件）， 当接收到 master 下发的"任务"后，Node 就要去完成任务（用 docker 运行一个指定的应用）。

Master 上的主要组件有：

• apiserver：提供了集群资源操作的统一接口，它通过与每个节点上的kubelet组件通信来控制节点的运行。kubectl客户端也是通过与apiserver交互来操作集群资源的。此外它还提供了认证、授权、访问控制、API注册和发现等机制。
• scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上，比如运维通过kubectl客户端命令根据推荐算法的Deployment配置文件与镜像启动100个Pod，master接受到请求后，scheduler就会根据每个节点的负载信息，决定将这100个Pod分配到哪些节点。
• controller manager：master上运行着很多控制器，如节点控制器、副本控制器、端点控制器等，用于故障检测、自动扩展、滚动更新等以保证集群的稳定运行，controller manager为这些控制器提供了一个统一的运行组件

跟master密切相关的还有两个组件

• etcd：它是一个高性能的分布式数据库，master用它来存储所有node上报的状态信息，实际也可以用其它DB代替。
• kubectl：它是一个客户端工具，运维通过它可以使用命shell命令来操作K8S集群资源。

每个Node主要包含下列一些组件

• kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理，它会周期性的向apiserver上报节点信息，使得master可以得知每个节点状态，合理的操作每一个节点。
• kube-proxy负责为Service提供cluster内部的服务发现和负载均衡，使得可以通过Service的name来访问服务。针对不在同一个节点的pod之间的通信，需要在本地配置路由转发信息，将pod之间的通信转为节点之间的通信，这些配置信息也是由kube-proxy来维护。

Kubernetes有一个基于web的用户界面，它可以图表化显示当前集群状态。

2、K8S网络模型

三种IP
在K8S的网络中主要会涉及三种IP：

• Node IP：容器宿主机也就是节点的ip，由路由器分配。
• Pod IP：K8s在每个Node里虚拟出的局域网，为Node上每个Pod分配一个IP，且同一宿主机下Pod位于相同网段，该地址是实际存在于某个网卡(可以是虚拟设备)上的。
• Service Cluster IP：由k8s分配给每个service的全局唯一的虚拟ip（VIP），service一般包含若干Pod，可以理解为这些Pod的反向代理。其原理是由kube-proxy通过Iptables规则重新定向到其本地端口，再均衡到后端Pod的。但VIP没有挂接到网络设备，外部不能直接访问。

设计原则
每个Pod都拥有一个独立的IP地址（IPper Pod），而且假定所有的pod都在一个可以直接连通的、扁平的网络空间中，无论这些Pod是否位于同一个宿主机。并且所有容器之间都是以非NAT（网络地址转换）的方式通信的，即容器的真实地址与看到的地址一致。

Linux网络名词基础

• 网络的命名空间（namespace）：Linux在网络栈中引入网络命名空间，将独立的网络协议栈隔离到不同的命令空间中，彼此间无法通信；docker利用这一特性，实现不容器间的网络隔离。
• Veth设备对：Veth设备对的引入是为了实现在不同网络命名空间的通信。
• Iptables/Netfilter：Netfilter负责在内核中执行各种挂接的规则(过滤、修改、丢弃等)，运行在内核模式中；Iptables模式是在用户模式下运行的进程，负责协助维护内核中Netfilter的各种规则表；通过二者的配合来实现整个Linux网络协议栈中灵活的数据包处理机制。
• 网桥：网桥是一个二层网络设备，通过网桥可以将linux支持的不同的端口连接起来,并实现类似交换机那样的多对多的通信。
• 路由：Linux系统包含一个完整的路由功能，当IP层在处理数据发送或转发的时候，会使用路由表来决定发往哪里。

同一Pod内容器间通信
同一Pod内的容器共享同一个网络命名空间，它们之间的访问可以用localhost地址 + 容器端口就可以访问。

同一Node中Pod之间的通信
同一Node中Pod的默认路由都是docker0的地址，由于它们关联在同一个docker0网桥上，地址网段相同，所有它们之间应当是能直接通信的。

不同Node中Pod间通信
不同Node中Pod间通信要满足2个条件： Pod的IP不能冲突； 将Pod的IP和所在的Node的IP关联起来。通过Node IP网络的转发，从而可以让Pod之间可以互相访问。这种转发时通过iptables实现的。

Service服务的暴露方式
在K8S中，服务一般时以Service的形式对外服务的，它是一组Pod的服务抽象，相当于一组Pod的代理或负载均衡器（Load Balancer），负责将请求分发给某个具体的Pod去处理；Service可以通过IP或域名的方式被其他应用访问，具体暴露方式有四种。

• Cluster IP：默认采用的是这种方式，仅限于集群内部访问，外部访问。IP可以自己手动指定，不指定的话服务启动时系统会动态分配。

spec:
  clusterIP: 10.0.0.1
  ports:
  - name: http

• NodePort：建立在Cluster IP类型之上，将服务暴露到所有节点的指定端口，访问任意一个node ip加端口号都可以访问到（前提没有指定node调度策略）服务，可以通过apiserver的配置文件查看端口暴露范围，类似于Docker Swarm中的Routing Mesh。这种模式K8S依然会为service分配集群IP地址，并将此作为NodePort的路由目标。配置示例如下，targetPort即为对外暴露的端口。

apiVersion: v1
kind: Service
metadata:
  name: test-nodportsvc
spec:
  type: NodePort
  selector:
    app: test-deploy
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

• LoadBalancer：建立在NodePort类型之上，其通过cloud provider提供的负载均衡器将服务暴露到集群外部。与NodePort类型的service的使用方法基本类似，需要指定外部的负载均衡器，示例如下。

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
  clusterIP: 10.0.171.239
  loadBalancerIP: 78.11.24.19
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 146.148.47.155

----结束----