k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，calico等。CNI插件存放位置：# cat /etc/cni/net.d/10-flannel.conflist
插件使用的解决方案如下：
虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信。
多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。
硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。
容器间通信：同一个pod内的多个容器间的通信，通过lo即可实现；
pod之间的通信： 同一节点的pod之间通过cni网桥转发数据包。 不同节点的pod之间的通信需要网络插件支持。
pod和service通信:
通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换。
pod和外网通信：iptables的MASQUERADE。
Service与集群外部客户端的通信；（ingress、nodeport、loadbalancer）
flannel网络简介
Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。
在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。
Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。
VXLAN，即Virtual Extensible LAN（虚拟可扩展局域网），是Linux本身支持的一网种网络虚拟化技术。VXLAN可以完全在内核态实现封装和解封装工作，从而通过“隧道”机制，构建出覆盖网络（OverlayNetwork）。
VTEP：VXLAN Tunnel End Point（虚拟隧道端点），在Flannel中VNI的默认值是1，这也是为什么宿主机的VTEP设备都叫flannel.1的原因。
Cni0: 网桥设备，每创建一个pod都会创建一对 vethpair。其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡）。
Flannel.1:TUN设备(虚拟网卡)，用来进行 vxlan报文的处理（封包和解包）。不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端。
Flanneld：flannel在每个主机中运行flanneld作为agent，它会为所在主机从集群的网络地址空间中，获取一个小的网段subnet，本主机内所有容器的IP地址都将从中分配。同时Flanneld监听K8s集群数据库，为flannel.1设备提供封装数据时必要的mac、ip等网络数据信息。
当容器发送IP包，通过veth pair发往cni网桥，再路由到本机的flannel.1设备进行处理。
VTEP设备之间通过二层数据帧进行通信，源VTEP设备收到原始IP包后，在上面加上一个目的MAC地址，封装成一个内部数据帧，发送给目的VTEP设备。
内部数据桢，并不能在宿主机的二层网络传输，Linux内核还需要把它进一步封装成为宿主机的一个普通的数据帧，承载着内部数据帧通过宿主机的eth0进行传输。
Linux会在内部数据帧前面，加上一个VXLAN头，VXLAN头里有一个重要的标志叫VNI，它是VTEP识别某个数据桢是不是应该归自己处理的重要标识。
flannel.1设备只知道另一端flannel.1设备的MAC地址，却不知道对应的宿主机地址是什么。在linux内核里面，网络设备进行转发的依据，来自FDB的转发数据库，这个flannel.1网桥对应的FDB信息，是由flanneld进程维护的。
linux内核在IP包前面再加上二层数据帧头，把目标节点的MAC地址填进去，MAC地址从宿主机的ARP表获取。
此时flannel.1设备就可以把这个数据帧从eth0发出去，再经过宿主机网络来到目标节点的eth0设备。目标主机内核网络栈会发现这个数据帧有VXLAN Header，并且VNI为1，Linux内核会对它进行拆包，拿到内部数据帧，根据VNI的值，交给本机flannel.1设备处理,flannel.1拆包，根据路由表发往cni网桥，最后到达目标容器
flannel支持多种后端：
Vxlan：vxlan //报文封装，默认。Directrouting //直接路由，跨网段使用vxlan，同网段使用host-gw模式。
host-gw： //主机网关，性能好，但只能在二层网络中，不支持跨网络， 如果有成千上万的Pod，容易产生广播风暴，不推荐
UDP： //性能差，不推荐
calico简介
flannel实现的是网络通信，calico的特性是在pod之间的隔离。
通过BGP路由，但大规模端点的拓扑计算和收敛往往需要一定的时间和计算资源。
纯三层的转发，中间没有任何的NAT和overlay，转发效率最好。
Calico 仅依赖三层路由可达。Calico 较少的依赖性使它能适配所有 VM、Container、白盒或者混合环境场景。
网络架构：
Felix：监听ECTD中心的存储获取事件，用户创建pod后，Felix负责将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。同样如果用户制定了隔离策略，Felix同样会将该策略创建到ACL中，以实现隔离。
BIRD：一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，路由的时候到这里来。
控制某个namespace下的pod的网络出入站规则
Configmap用于保存配置数据，以键值对形式存储。
configMap 资源提供了向 Pod 注入配置数据的方法。
旨在让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性。
典型的使用场景：
创建ConfigMap的4种方式：
使用字面值创建：
使用文件创建：
使用目录创建：
编写configmap的yaml文件创建
Secret对象类型用来保存敏感信息，例如密码、OAuth 令牌和 ssh key。
敏感信息放在secret 中比放在 Pod 的定义或者容器镜像中来说更加安全和灵活。
Pod 可以用两种方式使用secret：
作为volume 中的文件被挂载到 pod 中的一个或者多个容器里。
当kubelet 为 pod 拉取镜像时使用。
Secret的类型：
ServiceAccount：Kubernetes 自动创建包含访问 API 凭据的 secret，并自动修改 pod以使用此类型的secret。
Opaque：使用base64编码存储信息，可以通过base64 --decode解码获得原始数据，因此安全性弱。
kubernetes.io/dockerconfigjson：用于存储docker registry的认证信息。
ServiceAccount
Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的。它与User account不同：
User account是为人设计的，而service account则是为Pod中的进程调用Kubernetes API而设计；
User account是跨namespace的，而service account则是仅局限它所在的namespace；
每个namespace都会自动创建一个default service account
Token controller检测service account的创建，并为它们创建secret
开启ServiceAccount Admission Controller后
1、每个Pod在创建后都会自动设置spec.serviceAccount为default（除非指定了其他ServiceAccout）
2、验证Pod引用的service account已经存在，否则拒绝创建
3、如果Pod没有指定ImagePullSecrets，则把service account的ImagePullSecrets加到Pod中
4、每个container启动后都会挂载该service account的token和ca.c到/var/run/secrets/kubernetes.io/serviceaccount/
容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。首先，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失,因为容器会以干净的状态重建。其次，当在一个 Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件。 Kubernetes 抽象出 Volume 对象来解决这两个问题。
Kubernetes 卷具有明确的生命周期,与包裹它的 Pod 相同。 因此，卷比 Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。 当然，当一个 Pod 不再存在时，卷也将不再存在。也许更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。
卷不能挂载到其他卷，也不能与其他卷有硬链接。 Pod 中的每个容器必须独立地指定每个卷的挂载位置。
Kubernetes 支持下列类型的卷： • awsElasticBlockStore 、azureDisk、azureFile、cephfs、cinder、configMap、csi • downwardAPI、emptyDir、fc (fibre channel)、flexVolume、flocker • gcePersistentDisk、gitRepo (deprecated)、glusterfs、hostPath、iscsi、local、 • nfs、persistentVolumeClaim、projected、portworxVolume、quobyte、rbd • scaleIO、secret、storageos、vsphereVolume
• emptyDir卷 • 当 Pod 指定到某个节点上时，首先创建的是一个 emptyDir 卷，并且只要 Pod 在 该节点上运行，卷就一直存在。 就像它的名称表示的那样，卷最初是空的。 尽管 Pod 中的容器挂载 emptyDir 卷的路径可能相同也可能不同，但是这些容器都可 以读写 emptyDir 卷中相同的文件。 当 Pod 因为某些原因被从节点上删除时， emptyDir 卷中的数据也会永久删除。
• emptyDir 的使用场景： • 缓存空间，例如基于磁盘的归并排序。 • 为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行。 • 在 Web 服务器容器服务数据时，保存内容管理器容器获取的文件。 • 默认情况下， emptyDir 卷存储在支持该节点所使用的介质上；这里的介质可以是磁盘 或 SSD 或网络存储，这取决于您的环境。 但是，您可以将 emptyDir.medium 字段设 置为 "Memory"，以告诉 Kubernetes 为您安装 tmpfs（基于内存的文件系统）。 虽然 tmpfs 速度非常快，但是要注意它与磁盘不同。 tmpfs 在节点重启时会被清除，并且 您所写入的所有文件都会计入容器的内存消耗，受容器内存限制约束。
• hostPath 卷能将主机节点文件系统上的文件或目录挂载到您的 Pod 中。 虽然这不是大多数 Pod 需要的，但是它为一些应用程序提供了强大的逃生舱。 • hostPath 的一些用法有： • 运行一个需要访问 Docker 引擎内部机制的容器,挂载 /var/lib/docker 路径。 • 在容器中运行 cAdvisor 时，以 hostPath 方式挂载 /sys。 • 允许 Pod 指定给定的 hostPath 在运行 Pod 之前是否应该存在，是否应该创建以及应该以 什么方式存在。
• 当使用这种类型的卷时要小心，因为： • 具有相同配置（例如从 podTemplate 创建）的多个 Pod 会由于节点上文件的不同而在不同 节点上有不同的行为。 • 当 Kubernetes 按照计划添加资源感知的调度时，这类调度机制将无法考虑由 hostPath 使 用的资源。 • 基础主机上创建的文件或目录只能由 root 用户写入。您需要在 特权容器 中以 root 身份运 行进程，或者修改主机上的文件权限以便容器能够写入 hostPath 卷。
• PersistentVolume（持久卷，简称PV）是集群内，由管理员提供的网络存储的一部分。就像集群 中的节点一样，PV也是集群中的一种资源。它也像Volume一样，是一种volume插件，但是它的 生命周期却是和使用它的Pod相互独立的。PV这个API对象，捕获了诸如NFS、ISCSI、或其他 云存储系统的实现细节。 • PersistentVolumeClaim（持久卷声明，简称PVC）是用户的一种存储请求。它和Pod类似，Pod 消耗Node资源，而PVC消耗PV资源。Pod能够请求特定的资源（如CPU和内存）。PVC能够请 求指定的大小和访问的模式（可以被映射为一次读写或者多次只读）。 • 有两种PV提供的方式：静态和动态。 • 静态PV：集群管理员创建多个PV，它们携带着真实存储的详细信息，这些存储对于集群用 户是可用的。它们存在于Kubernetes API中，并可用于存储使用。 • 动态PV：当管理员创建的静态PV都不匹配用户的PVC时，集群可能会尝试专门地供给 volume给PVC。这种供给基于StorageClass。 • PVC与PV的绑定是一对一的映射。没找到匹配的PV，那么PVC会无限期得处于unbound未绑定 状态。
• 使用 • Pod使用PVC就像使用volume一样。集群检查PVC，查找绑定的PV，并映射PV给Pod。对 于支持多种访问模式的PV，用户可以指定想用的模式。一旦用户拥有了一个PVC，并且 PVC被绑定，那么只要用户还需要，PV就一直属于这个用户。用户调度Pod，通过在Pod的 volume块中包含PVC来访问PV。
• 释放 • 当用户使用PV完毕后，他们可以通过API来删除PVC对象。当PVC被删除后，对应的PV就 被认为是已经是“released”了，但还不能再给另外一个PVC使用。前一个PVC的属于还存 在于该PV中，必须根据策略来处理掉。
• 回收 • PV的回收策略告诉集群，在PV被释放之后集群应该如何处理该PV。当前，PV可以被 Retained（保留）、 Recycled（再利用）或者Deleted（删除）。保留允许手动地再次声明 资源。对于支持删除操作的PV卷，删除操作会从Kubernetes中移除PV对象，还有对应的外 部存储（如AWS EBS，GCE PD，Azure Disk，或者Cinder volume）。动态供给的卷总是 会被删除。
• StorageClass提供了一种描述存储类（class）的方法，不同的class可能会映射到不同的服务质 量等级和备份策略或其他策略等。
• 每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段， 这些字段会在 StorageClass需要动态分配 PersistentVolume 时会使用到。
• StorageClass的属性 • Provisioner（存储分配器）：用来决定使用哪个卷插件分配 PV，该字段必须指定。可以指 定内部分配器，也可以指定外部分配器。外部分配器的代码地址为： kubernetesincubator/external-storage，其中包括NFS和Ceph等。
• Reclaim Policy（回收策略）：通过reclaimPolicy字段指定创建的Persistent Volume的回收 策略，回收策略包括：Delete 或者 Retain，没有指定默认为Delete。
• 更多属性查看：https://kubernetes.io/zh/docs/concepts/storage/storage-classes/
NFS Client Provisioner是一个automatic provisioner，使用NFS作为存储，自动创建PV和对应的 PVC，本身不提供NFS存储，需要外部先有一套NFS存储服务。 • PV以 ${namespace}-${pvcName}-${pvName}的命名格式提供（在NFS服务器上） • PV回收的时候以 archieved-${namespace}-${pvcName}-${pvName} 的命名格式（在NFS 服务器上） • nfs-client-provisioner源码地址：https://github.com/kubernetes-incubator/externalstorage/tree/master/nfs-client
• 默认的 StorageClass 将被用于动态的为没有特定 storage class 需求的 PersistentVolumeClaims 配置存储：（只能有一个默认StorageClass） • 如果没有默认StorageClass，PVC 也没有指定storageClassName 的值，那么意 味着它只能够跟 storageClassName 也是“”的 PV 进行绑定。
