文章目录

第三章 Kubernetes集群网络，安全与存储3.1 Kubernetes集群网络3.1.1 Node网络3.1.2 Pod网络3.2.3 Service网络 3.2 Kubernetes集群网络的设计需求3.3 Kubernetes集群网络实现3.3.1 kubernetes网络实现3.3.2 CNI工作流程 3.4 Pod网络实现原理和网络方案对比3.4.1 网络实现原理3.4.2 三种方案对比3.4.3 Pod的不足 3.5 Service网络实现原理3.5.1 Service的特性3.5.2 Service网络3.5.3 Service网络原理 3.6 Kube-Apiserver安全模型和安全传输3.6.1 APIServer的安全验证环节3.6.2 传输安全 3.7 APISrever安全验证3.7.1 身份验证环节关注API请求的Header3.7.2 Kubernetes中的User3.7.2-1 Normal User3.7.2-2 ServiceAccount 3.7.3 身份验证策略3.7.4 APIServer授权3.7.5 APIServer准入控制 3.8 Kubernetes集群存储3.8.1 Kubernetes Volume3.8.2 PersistentVolume（PV）3.8.3 PersistentVolumeClaim(PVC)3.8.4 StorageClass3.8.5 动态PV供给3.8.6 PV的状态和回收策略

第三章 Kubernetes集群网络，安全与存储

3.1 Kubernetes集群网络

3.1.1 Node网络

节点网络集群中所有物理节点所组成的网络，各worker节点以及master节点组成的网络无论集群是以那种方式安装的，Node网络就是宿主机所有的网络

3.1.2 Pod网络

一般学常说的网络就是Pod网络，也是k8s集群中最重要的网络 容器不是k8s集群中的一等公民Pod是一个或者多个容器的聚合体，始终位于同一位置，作为整体一并调度，在上下文(Contexts)中运行Contextx是一组linux命名空间(cgroups)Pod中的容器共享IP地址，并且可以通过localhost找到彼此，不同的Pod不能互相通信，以及通过IPC调用

3.2.3 Service网络

Service是k8s中一种虚拟抽象，代表一组Pod的抽象K8s为每个Service赋予了一个虚拟IP地址，即server cluster的IP地址，这些地址在一个设定好的网段内，这里称为Service网络Service主要起到服务发现，负载均衡的功能

注意： 以上3种网络地址空间是互不相交的

3.2 Kubernetes集群网络的设计需求

网络设计者们面对的问题 如何实现跨节点的Pod间的通信(东西向流量)Pod中的服务如何被其他的Pod发现，并且当访问这个服务时的流量被负载均衡Pod中的服务如何暴露到集群外部并服务外部的请求(南北向流量) 网络设计的基本要求 让Pod像传统物理主机或者虚拟机一样使用 所有Pod间均应可以在无需NAT的情况下直接通信所有集群节点与所有集群的Pod之间均应可以在无需NAT的情况下直接通信容器自身的地址和其他Pod看到它的地址是同一个地址

3.3 Kubernetes集群网络实现

3.3.1 kubernetes网络实现

kubernetes并idme原生内置某种网络实现 CNI(Container Network Interface)成为kubernetes网络第三方实现的主流规范接口CNI最初是由CoreOS提出的一个容器网络规范CNI是目前容器运行时与网络实现之间最简单的接口规范之一

3.3.2 CNI工作流程

容器runtime调用CNI网络插件实现网络配置 一般CNI网络插件是以独立的可执行文件形式存在调用插件时，数据通过两种方式传递给插件 环境变量标准输入 CNI将容器添加到特定网络的一般流程

3.4 Pod网络实现原理和网络方案对比

3.4.1 网络实现原理

可能的Pod网络实现选择

二层(交换)方案 利用二层网络数据交换实现Pod网络 Pods与Nodes处于同一个二层广播域Node的物理网上桥接到虚拟网上，开户混杂模式，这样可以将目的MAC地址不是自己的包转发到Linux Bridge适用于小型kubernetes部署 三层(路由)方案 可用于生产环境的Pod网络实现方案 通过路由而不是交换的方式实现Pod网络更具有扩展性在集群添加或删除Node时自动维护路由表 Overlay方案 优点: 最大程度的保留原网络结构，保证原有网络尽量不做改造不足: Overlay网络方案在传输性能上无法与二层、三层方案相比在节点上维护Overlay网络相关路由，实现Pod与Node间的直接通信

3.4.2 三种方案对比

- 二层方案: 简单，性能好，但难于扩展，适合小规模实验环境 - 三层方案: 目前生产环境主流使用的一种方案，原生网络的性能是它的优势，同时还具备相比于二层方案更为良好的扩展性 - Olveray方案: 最大优势不改动现有网络结构，但额外负担大，导致网络性能不佳

3.4.3 Pod的不足

Pod的短暂性问题给开发者带来了开发的复杂度

Pod如何向集群内的其他Pod提供稳定的服务一组运行相同服务程序的Pods如何向集群内的其他Pods提供稳定的服务一种服务如何确定和动态管理可以提供这种服务的Pod集合？并且Pod集合是如何实现分担客户端的请求流量的？

3.5 Service网络实现原理

Service解决了因Pod的短暂性给开发者带来的开发复杂性问题

3.5.1 Service的特性

Service是面积Kubernetes云应用的基本构建单元Service通过Pod Label以及Label Selector与Pod(endpoint)自动建立关联Service会将来自客户端的语法流量自动负载均衡到后面的endpoints上

3.5.2 Service网络

Service网络是什么

Cluster IP: Kubernetes集群赋予每个Service在集群内部不变的IP地址Service网络: 所有service的ClusterIP地址组合而成的"虚拟网络"通过NodePort将服务暴露到集群外部 外部请求 --> NodeIP: NodePort --> ClusterIP: Port --> ContainerIP: TargetPort

3.5.3 Service网络原理

Service网络的实现者: kube-proxy

kube-proxy以daemonset pod的形式运行在集群内的每个节点上kube-proxy通过iptables实现nodePord到集群内部Service Port再到Pod中container target port的流量转发kube-proxy通过不iptables实现service流量转发到pod负载均衡

3.6 Kube-Apiserver安全模型和安全传输

kubernetes集群安全

3.6.1 APIServer的安全验证环节

传输安全(Transport Security)身份验证(Authentication)授权(Authorization)准入控制(Admission Control)

3.6.2 传输安全

传输安全是APIServer安全模型的基础

APIServer的非安全端口(–insecure-port)仅用于测试或其他master组件与APIServer交互APIServer的安全端口(–insecure-port=6443)所有内外部发起的到APIServer的请求均通过安全端口与APIServer进行交互

3.7 APISrever安全验证

身份验证环节关注api请求的Header

3.7.1 身份验证环节关注API请求的Header

目标: 身份验证，并识别出请求所代表的kubernetes user信息验证策略: 支持client certificates, bearer tokens, HTTP basic auth, authenticating rroxy结果: 通过身份验证的请求会被附上一些身份信息属性，包括Username, UID, Gruops以及一些对授权环节可能有用的信息

3.7.2 Kubernetes中的User

Normal User和ServiceAccount

3.7.2-1 Normal User

kubernetes中没有任何对象可以表示Normal User

3.7.2-2 ServiceAccount

由kubernetes管理的，用于pod访问apiserver的用户

匿名请求: username - system:anonymouse, group - system:unauthenticated

3.7.3 身份验证策略

支持多种验证策略，彩"短路验证"方式

客户端证书验证: --client-ca-file=SOMEFILE Username={CN}, Groups={Organizations}Basic Auth: --basic-auth-file=SOMEFILE Authorization: Basic BASE64ENCODED(USER:PASSWORD) -> password,user,uid,"group1,group2,group3" Bearer Token: --token-auth-file=SOMEFILE Authorization: Bearer THETOKEN -> token,user,uid,"group1,group2,group3" Service Account 由kubernetes自动创建，使用签名bearer token对请求进行验证组成: Service Account- > {name, namespace, secret}; secret -> {ca.crt, namespace, token}secret对象自动挂载到Pod内/var/run/secrets/kubernetes.io/serviceaccount路径下 Username: system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT) Groups:system:serviceaccounts, system:serviceaccounts(NAMESPACE)

3.7.4 APIServer授权

根据请求信息和授权策略判断请求是否具有操作目标对象的权限

支持多种授权模块：ABAC, RBAC, Node, Webhook启动授权模块: --authorization-mode=xx,yy开户多种授权模型时，采用短路方式授权kubernetes1.6以后，RBAC逐渐成为主流的授权模型kubernetes RBAC实现: 通过Role和RoleBinding实现了RBAC中三类元素的映射连接

3.7.5 APIServer准入控制

API请求的结果写入etcd之前的最后一道安全防线

kubernetes内转了一些admission controllers,可以通过apiserver的–admission-control配置开户意义: 和APIServer配合共同实现一些高级功能工作方式: 请求依次通过所有admission controller, 如果有一个controller返回失败，则请求失败

3.8 Kubernetes集群存储

kubernetes非常适合部署无状态的应用，但是还是有好多应用需要将数据持久化到磁盘上真正承受工作负载的是Pod内的一个容器，容器重启数据将丢失

3.8.1 Kubernetes Volume

Volume生命周期与其所依附的Pod相同 kubernetes volume本质是一个目录要使用volume, 需要为Pod指定spec.volumes字段以将它挂载到容器的位置(spec.containers.volumeMounts字段)支持多种Volume Type: cephfs, configMap, hostPath, nfs, rbd, secret, local, emptyDir等

3.8.2 PersistentVolume（PV）

PersistentVolume:

PV是集群中的资源，可以把pv看成volume pluginpv生命周期独立于podpv对象封装了底层存储卷实现的细节PV访问模式 ReadWriteOnceReadOnlyManyReadWriteMany

3.8.3 PersistentVolumeClaim(PVC)

PVC是对pv资源的请求

pvc负责请求pv的大小和访问方式绑定: pvc将与满足请求的pv资源一对一绑定使用: 像Volume一样

3.8.4 StorageClass

PVC按类别(class)匹配PV

PVC负责请求PV的大小和访问方式可以为PV指定storageClassName属性，标识pv归属哪上一个Class绑定: 一个请求绑定特定Class的pvc只能绑定拥有该Class属性的PV，一个没有指定Class的PV仅可以绑定没有特定Class属性字段的PV

3.8.5 动态PV供给

基于StorageClass的动态PV供给

开启动态PV供给: StorageClass和使用StorageClass的PVC集群默认动态PV供给行为: 存在Default StoargeClass, PVC未指定StorageClass集群至多存在一个Default StorageClass

3.8.6 PV的状态和回收策略

PV的状态: Available/Bound/Released/FailedPV的回收策略: Retain/Recycle/Delete当前，只有NFS和HostPath支持Recycle策略，AWS EBS, GCE PD, Azure Disk, Cinder卷支持Delete策略