kubernetes（k8s）知识总结（第3期）

1. PV 与 PVC

PV 是持久卷（Persistent Volume）的首字母缩写。通常情况下，可以事先在 k8s 集群创建 PV 对象：

apiVersion: v1
kind: PersistentVolume
metadata:name: nfs
spec:storageClassName: manualcapacity:storage: 1GiaccessModes:- ReadWriteManynfs:server: 10.244.1.4path: "/"

PVC 是持久卷声明（PersistentVolumeClaim）的首字母缩写，描述的是 Pod 所希望使用的持久化存储的属性。PVC 对象通常由平台的用户创建，或者以 PVC 模板的方式成为 StatefulSet 的一部分，然后由 StatefulSet 控制器负责创建带编号的 PVC。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: nfs
spec:accessModes:- ReadWriteManystorageClassName: manualresources:requests:storage: 1Gi

用户创建的 PVC 要真正被容器使用，就必须先和某个符合条件的 PV 进行绑定，要检查一下两个条件：

（1）PV 和 PVC 的 spec 字段，PV 的存储（storage）大小必须满足 PVC 的要求。

（2）PV 和 PVC 的 storageClassName 字段必须一样。

在成功地将 PVC 和 PV 进行绑定之后，Pod 就能够像使用 hostPath 等常规类型的 Volume 一样，在自己的 YAML 文件里声明使用这个 PVC 了。

apiVersion: v1
kind: Pod
metadata:labels:role: web-frontend
spec:containers:- name: webimage: nginxports:- name: webcontainerPort: 80volumeMounts:- name: nfsmountPath: "/usr/share/nginx/html"volumes:- name: nfspersistentVolumeClaim:claimName: nfs

 可以看到，Pod 需要做的，就是在 volumes 字段里声明自己要使用的 PVC 的名字。接下来，等这个 Pod 创建之后，kubelet 就会把该 PVC 所对应的 PV 挂载在这个 Pod 容器内的目录上。

在 k8s 中实际上存在着一个专门处理持久化存储的控制器 Volume Controller。它维护着多个控制循环，其中一个就是将 PV 和 PVC 进行关联的 Persistent Volume Controller。它会不断查看当前每一个 PVC 是否已经处于已绑定（Bound）状态。如果不是，它就会遍历所有可用的 PV，并尝试将其与这个 PVC 进行绑定。所谓的绑定，其实就是将这个 PV 对象的名字填在了 PVC 的 spec.volumeName 字段上。

那么，这个 PV 是如何变成容器里的一个持久化存储的呢？所谓容器的 Volume，就是将一个宿主机上的目录跟一个容器里的目录绑定在了一起。所谓的持久化，指的就是该宿主机上的目录具备持久性，该目录里的文件既不会因为容器的删除而被清理，也不会跟当前的宿主机绑定。所以，大多数情况下，持久化 Volume 的实现往往以来一个远程存储服务。k8s 需要做的，就是使用这些存储服务来为容器准备一个持久化的宿主机目录，以供将来进行绑定挂载时使用。

准备宿主机目录的过程分为两个阶段：

（1）第一阶段（Attach）

当一个 Pod 调度到一个节点上之后，kubelet 就要负责为这个 Pod 创建它的 Volume 目录，默认是宿主机上的一个路径：

/var/lib/kubelet/pods/<Pod 的 ID>/volumes/kubernetes.io~<Volume 类型>/<Volume 名字>

接下来，kubelet 就要调用 Volume 所在平台的 API，将目标存储盘挂载到 Pod 所在的宿主机上。

（2）第二阶段（Mount）

为了能够使用该远程磁盘，kubelet 还要格式化这个磁盘设备，然后把它挂载到宿主机指定的挂载点上。

经过了两阶段处理，就得到了一个持久化的 Volume 宿主机目录。接下来 kubelet 只要把这个 Volume 目录通过 CRI 里的 Mounts 参数传递给 Docker，然后就可以为 Pod 里的容器挂载这个 Volume 了。

2. K8s 网络原理

1. 单机容器网络的实现原理

Linux 容器能看见的网络栈，是隔离在它自己的 Network Namespace 中的。

网络栈包括了网卡、回环设备、路由表和 iptables 规则。对于一个进程来说，这些要素构成了它发起和相应网络请求的基本环境。

作为容器，它可以声明直接使用宿主机的网络栈（-net=host），即不开启 Network Namespace。

$ docker run -d -net=host --name nginx-host nginx

在这种情况下，容器启动后直接监听的就是宿主机的 80 端口。像这样直接使用宿主机的网络栈的方式，虽然可以为容器提供良好的网络性能，但会不可避免地带来共享网络资源的问题，比如端口冲突。所以，我们希望容器进程能使用自己 Network Namespace 里的网络栈，即拥有自己的 IP 地址和端口。

那么，这个被隔离的容器进程跟其他 Network Namespace 里的容器进程交互就是接下来要介绍的。可以把每个容器看作一台主机，如果要实现网络通信，最直接的办法就是用网线把他们连接到一台交换机上。在 Linux 中，能起到虚拟交换机作用的网络设备就是网桥。它是一个在数据链路层工作的设备，主要功能是根据 MAC 地址学习将数据包转发到网桥的不同端口上。为了实现这个目的，Docker 会默认在宿主机上创建一个名叫 docker0 的网桥，凡是与 docker0 网桥连接的容器，都可以通过他来进行通信。将容器连接到 docker0 网桥的虚拟设备是 Veth Pair。Veth Pair 被创建出来后，总是以两张虚拟网卡的形式成对出现。从其中一张“网卡”发出的数据可以直接出现在对应的“网卡”上，哪怕这两张“网卡”在不同的 Network Namespace 里。

2. 容器跨主机网络的实现原理

（1）VXLAN

VXLAN（virtual extensible LAN，虚拟可扩展局域网）是 Linux 内核本身就支持的一种网络虚拟化技术。VXLAN 覆盖网络的设计思想是，在现有的三层网络之上“覆盖”一层虚拟的、由内核 VXLAN 模块负责维护的二层网络，使得这个二层网络上的“主机”之间可以像在同一个局域网里那样自由通信。为了能够在二层网络上打通“隧道”，VXLAN 会在宿主机上设置一个特殊的网络设备作为“隧道”的两端。这个设备叫做 VTEP（VXLAN tunnel end point，虚拟隧道端点）。在进行通信的流程中，VTEP 设备既有 IP 地址，也有 MAC 地址。

比如现在宿主机A Node1 的 container-1 要访问在不同主机上的 Node2 的 container-2。当 container-1 发出请求之后，这个 IP 包会先出现在 docker0 网桥，然后被路由到本机的 VTEP 设备进行处理，也就是来到了“隧道的入口”。为了能将 IP 包封装并发送到正确的宿主机，VXLAN 就需要找到这条隧道的出口，即目的宿主机的 VTEP 设备。而这个设备信息是由每台宿主机上的 flanneld 进程负责维护的，每个节点被添加到 Flannel 网络之后，在其他已加入的网络节点上的 flanneld 就会添加一条路由规则。这些 VTEP 设备之间需要想办法组成一个虚拟的二层网络，即通过二层数据帧进行通信。可以根据 IP 地址通过 ARP 记录查到 MAC 地址，这个 ARP 记录也是在新节点启动时自动添加到其他节点的。现在得到了一个二层数据帧，需要注意的是，以上封包过程只是加一个二层头，不会改变 IP 包的内容。接下来 Linux 内核还要把二层数据帧进一步封装成为宿主机网络里的一个普通的数据帧，也叫“外部数据帧”，好让它通过宿主机的 eth0 网卡进行传输。首先，Linux 内核会在二层数据帧前面加上一个特殊的 VXLAN 头，这个 VXLAN 头里有一个重要的标志，叫做 VNI，它是 VTEP 设备识别某个数据帧是否应该归自己处理的重要标识。然后， Linux 内核会把这个数据帧封装进一个 UDP 包里发出去。但是，这个 VTEP 设备只知道另一端的 MAC 地址，不知道 IP 地址。在这种场景中，VTEP 设备要扮演一个“网桥”的角色，在二层网络进行 UDP 包的转发。在 Linux 内核中，“网桥”设备进行转发的依据来自一个叫做 FDB （forwarding database）的转发数据库。接下来的流程就是正常宿主机网络上的封包工作。在前面加上一个 IP 头，组成一个 IP 包，这个 IP 头里会填上之前通过 FDB 查询出来的 IP 地址。然后，Linux 内核再在这个 IP 包前面加上二层数据帧头，并把 MAC 地址填进去。这样，封包工作就完成了。

接下来，Node1 上的 VTEP 设备就可以把这个数据帧从 Node1 的 eth0 网卡发出去，这个帧会经过宿主机网络来到 Node2 的 eth0 网卡。Node2 的内核网络栈会发现这个数据帧里有 VXLAN 头，所以 Linux 内核会对它进行拆包，获取里面的数据帧，然后根据 VNI 值把它交给 Node2 上的 VTEP 设备。VTEP 设备会进一步拆包，取出里面的 IP 包。接下来就到了单机容器网络的处理流程。最终，IP 包就进入了 container-2 的 Network Namespace 里。

（2）host-gw

假设现在 Node1 上的 container-1 要访问 Node2 上的 container-2，使用 host-gw 模式之后，flanneld 会在宿主机上创建这样一条规则，以 Node1 为例：

10.244.1.0/24 via 10.168.0.3 dev eth0

这条路由规则的含义是，目的 IP 地址属于 10.244.1.0/24 网段的 IP 包应该经过本机的 eth0 设备发出，它的下一跳地址是 10.168.0.3，这个下一跳地址对应的正是目的宿主机 Node2。配置了下一跳地址，接下来当 IP 包从网络层进入链路层封装成帧时，eth0 设备就会使用下一跳地址对应的 MAC 地址，作为该数据帧的目的 MAC 地址。这样，这个数据帧就会从 Node1 通过宿主机的二层网络顺利到达 Node2 上。

Node2 的内核网络栈从二层数据帧里获取 IP 包后，会“看到”这个 IP 包的目的 IP 地址是 10.244.1.3，即 container-2 的 IP 地址。此时，根据 Node2 上的路由表，IP 包会进入 cni0 网桥，进而进入 container-2 当中。

由此可见，host-gw 模式的工作原理其实就是将每个 Flannel 子网的下一跳设置成了该子网对应的宿主机的 IP 地址。

（3） Calico 项目

Calico 项目提供的网络解决方案与 Flannel 的 host-gw 几乎完全一样。Calico 也会在每台宿主机上添加一条格式如下的路由规则：

<目的容器 IP 地址段> via <网关的 IP 地址> dev eth0

其中，网关的 IP 地址正是目的容器所在宿主机的 IP 地址。这个三层网络方案得以正常工作的核心是为每个容器的 IP 地址找到对应的下一跳的网关。不同于 Flannel 通过 etcd 和宿主机上的 flanneld 来维护路由信息的做法，Calico 使用 BGP（border gateway protocol，边界网关协议） 来自动地在整个集群中分发路由信息。

Calico 项目的架构由以下三个部分组成：

（1）Calico 的 CNI 插件。

（2）Felix。这是一个 DaemonSet，负责在宿主机上插入路由规则，以及维护 Calico 所需的网络设备等工作。

（3）BIRD。BGP 的客户端，专门负责在集群里分发路由规则信息。

下面介绍一下 Calico 的工作原理：

Calico 的 CNI 插件会为每个容器设置一个 Veth Pair 设备，然后把其中的一端放置在宿主机上。此外，由于 Calico 没有使用 CNI 的网桥模式，因此 Calico 的 CNI 插件还需要在宿主机上为每个容器的 Veth Pair 设备配置一条路由规则，用于接收传入的 IP 包。有了这样的 Veth Pair 设备之后，容器发出的 IP 包就会经过 Veth Pair 设备出现在宿主机上。然后，宿主机网络栈就会根据路由规则的下一跳 IP 地址，把它们转发给正确的网关。接下来的流程就跟 Flannel 的 host-gw 模式完全一致了。 

3. 网络隔离：Network Policy

在 K8s 里，网络隔离能力是依靠一种专门的 API 对象来描述的，它就是 NetworkPolicy。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: test-network-policynamespace: default
spec:podSelector:matchLabels:role: dbpolicyTypes:- Ingress- Egressingress:- from:- ipBlock:cidr: 172.17.0.0/16except:- 172.17.1.0/24- namespaceSelector:matchLabels:project: myproject- podSelector:matchLabels:role: frontendports:- protocol: TCPport: 6379egress:- to:- ipBlock:cidr: 10.0.0.0/24ports:- protocol: TCPport: 5978

在这个例子中， 首先会看到 podSelector 字段。它的作用是定义这个 NetworkPolicy 的限制范围，比如当前 Namespace 里携带了 role=db 标签的 Pod。

如果把 podSelector 字段留空：

spec:podSelector: {}

那么这个 NetworkPolicy 就会作用于当前 Namespace 下的所有 Pod。

NetworkPolicy 定义的规则其实就是“白名单”。例如，上面的例子里，在 policyTypes 字段定义了这个 NetworkPolicy 的类型是 ingress 和 egress，即它既会影响流入请求，也会影响流出请求。然后在 ingress 字段定义了 from 和 ports，即允许流入的“白名单”和端口。在这个“白名单”里指定了 3 种并列的情况，分别是 ipBlock、namespaceSelector 和 podSelector。在 egress 字段定义了 to 和 ports，即允许流出的“白名单”和端口。这里的定义方法与 ingress 类似，只是 ipBlock 字段指定的是目的地址和网段。

综上所述，这个 NetworkPolicy 对象指定的隔离规则如下所示：

（1）该隔离规则只对 default Namespace 下携带了 role=db 标签的 Pod 有效。限制的请求类型包括 ingress 和 egress。

（2）K8s 会拒绝任何对被隔离 Pod 的访问请求，除非请求来自以下“白名单”里的对象，并且访问的是被隔离 Pod 的 6379 端口。这些“白名单”对象包括：

        1）default Namespace 里携带了 role=fronted 标签的 Pod

        2）任何 Namespace 里携带了 project=myproject 标签的 Pod

        3）任何源地址属于 172.17.0.0/16 网段，且不属于 172.17.1.0/24 网段的请求

（3）K8s 会拒绝被隔离 Pod 对外发起任何请求，除非请求的目的地属于 10.0.0.0/24 网段，并且访问的是该网段地址的 5978 端口。

3. Service

K8s 之所以需要 Service，一方面是因为 Pod 的 IP 不是固定的，另一方面是因为一组 Pod 实例之间总会有负载均衡的需求。

apiVersion: v1
kind: Service
metadata:name: hostnames
spec:selector:app: hostnamesports:- name: defaultprotocol: TCPport: 80targetPort: 9376

这个例子中，使用了 selector 字段来声明这个 Service 只携带 app: hostnames 标签的 Pod。 并且，这个 Service 的 80 端口代理的是 Pod 的 9376 端口。

应用的 Deployment 如下所示：

apiVersion: apps/v1
kind: Deployment
metadata:name: hostnames
spec:selector:matchLabels:app: hostnamesreplicas: 3template:metadata:labels:app: hostnamesspec:containers:- name: hostnamesimage: k8s.gcr.io/serve_hostnameports:- containerPort: 9376protocol: TCP

被 selector 选中的 Pod 称为 Service 的 Endpoint，可以使用 kubectl get ep 查看。只有处于 Running 状态，且 readinessProbe 检查通过的 Pod，才会出现在 Service 的 Endpoints 列表里。当某个 Pod 出现问题时，K8s 会自动从 Service 里将其移除。

此时，通过该 Service 的 VIP 地址，就可以访问到它所代理的 Pod 了。 这个 VIP 地址是 K8s 自动为 Service 分配的。Service 提供的是轮询方式的负载均衡。这种方式称为 ClusterIP 模式的 Service。

Service 的访问信息在 K8s 集群之外是无效的。所谓的 Service 的访问入口，其实就是每台宿主机上由 kube-proxy 生成的 iptables 规则，以及由 kube-dns 生成的 DNS 记录。一旦离开这个集群，这些信息对用户就没有作用了。如何从外部访问 K8s 集群里的 Service？最常用的方式是 NodePort：

apiVersion: v1
kind: Service
metadata:name: my-nginxlabels:run: my-nginx
spec:type: NodePortports:- nodePort: 8080port: 30080targetPort: 80protocol: TCPname: http- nodePort: 443port: 30443protocol: TCPname: httpsselector:run: my-nginx

在这个 Service 里，它的类型是 type=NodePort。然后在 ports 字段里声明了 Service 的 8080 端口代理 Pod 的 80 端口，Service 的 443 端口代理 Pod 的 443 端口。当然，如果不显式声明 nodePort 字段，K8s 就会为你分配随机的可用端口来设置代理。这个端口的默认范围是 30000~32767，你可以通过 kube-apiserver 的 --service-node-port-range 参数来修改。此时要访问这个 Service，只需要访问：

<K8s集群中任何一台宿主机的IP地址>:8080

 这样就可以访问到某一个被代理的 Pod 的 80 端口了。

从外部访问 Service 的另一种方式适用于公有云上的 K8s 服务，此时可以制定一个 LoadBalancer 类型的 Service：

apiVersion: v1
kind: Service
metadata:name: example-service
spec:ports:- port: 8765targetPort: 9376selector:app: exampletype: LoadBalancer

在公有云提供的 K8s 服务里，都使用了一个叫做 CloudProvider 的转接层来跟公有云本身的 API 进行对接。所以，在上述 LoadBalancer 类型的 Service 提交后，K8s 就会调用 CloudProvider 在公有云上为你创建一个负载均衡服务，并且把被代理的 Pod 的 IP 地址配置给负载均衡服务作为后端。 

4. Ingress

Ingress 是一种全局的、为了代理不同后端 Service 而设置的负载均衡服务。

举个例子，假如有一个站点：https://cafe.example.com，其中 https://cafe.example.com/coffee 对应“咖啡点餐系统”，而 https://cafe.example.com/tea 对应“茶水点餐系统”。这两个系统分别由名叫 coffee 和 tea 的两个 Deployment 来提供服务。下面的 Ingress 可以实现当用户访问不同域名时，能够访问不同的 Deployment：

apiVersion: extensions/vibeta1
kind: Ingress
metadata:name: cafe-ingress
spec:tls:- hosts:- cafe.example.comsecretName: cafe-secretrules:- host: cafe.example.comhttp:paths:- path: /teabackend:serviceName: tea-svcservicePort: 80- path: /coffeebackend:serviceName: coffee-svcservicePort: 80

host 字段定义的值就是这个 Ingress 的入口。这就意味着当用户访问 cafe.example.com 时，实际上访问的是这个 Ingress 对象。这样，K8s 就能使用 IngressRule 来对你的请求进行下一步转发了。接下来 IngressRule 规则的定义则依赖 path 字段。这里的每一个 path 都对应一个后端的 Service。

一个 Ingress 对象的主要内容，实际上就是一个“反向代理”服务的配置文件的描述。而这个代理服务对应的转发规则就是 IngressRule。这就是为什么在每条 IngressRule 里，需要有一个 host 字段作为这条 IngressRule 的入口，还需要有一系列 path 字段来声明具体的转发策略。

在实际使用中，只需要从社区里选择一个具体的 Ingress Controller，把它部署到 K8s 集群中即可。 

5. RBAC（基于角色的权限控制）

这里需要明确 3 个基本概念：

（1）Role：角色，他其实是一组规则，定义了一组对 K8s API 对象的操作权限

（2）Subject：被作用者，既可以是“人”，也可以是“机器”，也可以是在 K8s 里定义的“用户”

（3）RoleBinding：定义了“被作用者”和“角色”间的绑定关系

Role 实际上就是一个 K8s 的 API 对象：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: mynamespacename: example-role
rules:
- apiGroups: [""]resources: ["pods"]verbs: ["get", "watch", "list"]

这个 Role 对象指定了它能产生作用的 Namespace 是 mynamespace。然后，这个 Role 对象的 rules 字段就是它所定义的权限规则。在上面的例子里，这条规则的含义是，允许“被使用者”对 mynamespace 下面的 Pod 对象进行 GET、WATCH 和 LIST 操作。那么，这个“被作用者”是如何制定的呢？通过 RoleBinding 来实现：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: example-rolebindingnamespace: mynamespace
subjects:
- kind: Username: example-userapiGroup: rbac.authorization.k8s.io
roleRef:kind: Rolename: example-roleapiGroup: rbac.authorization.k8s.io

这个 RoleBinding 对象里定义了一个 subjects 字段，即“被作用者”。它的类型是 User，这个用户的名字是 example-user。接下来，可以看到一个 roleRef 字段。通过该字段，RoleBinding 对象可以直接通过名字来引用前面定义的 Role 对象，从而定义了“被作用者”和“角色”之间的绑定关系。

Role 和 RoleBinding 对权限的限制规则仅在它们自己的 Namespace 内有效。如果某个 Role 想作用于所有的 Namespace 时，就必须使用 ClusterRole 和 ClusterRoleBinding 了：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: example-clusterrole
rules:
- apiGroups: [""]resources: ["pods"]verbs: ["get", "watch", "list"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: example-clusterrolebinding
subjects:
- kind: Username: example-userapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: example-clusterroleapiGroup: rbac.authorization.k8s.io

这意味着名叫 example-user 的用户拥有对所有 Namespace 的 Pod 进行 GET、WATCH 和 LIST 操作的权限。