k8s的3个网络
1.node网络 ，宿主机的网络
2.pod网络 pod共享上下文，共享进程通信 ，localhost通信，共享namespace
3.service网络 服务发现负载均衡
pod网络设计的三个考虑：
1.所有pod间应该无需NAT直接能通信
2.所有集群与所有pod 可以在 无需NAT的情况下直接通信
3.容器自身的地址和其他pod看到它的地址是同一个地址

每一个pod都有一个虚拟ip，不需要考虑容器端口映射
k8s的网络实现
1.k8s自己没有内置的某种网络的实现
2.CNI （container Network Interface）成为了k8s的网络的第三方主流接口规范
3.CNI是coreos提出的网络规范
4.CNI是目前容器运行时与网络实现之间最简单的接口规范之一
CNI插件模型
1.CNI需要自己特有的namespace
2.CNI通过读取配置文件进行配置，一般是以独立的可执行文件形式存在的
3.调用插件方式：环境变量+标准输出
4.创建pause网卡
pod网络实现原理
1.二层交换方案

2.三层（路由）方案
具有扩展性，集群添加，删除node时候自动维护路由表
calico
3.overlay方案
优点：保留原网络的网络结构，保证原网络劲量不做改造
不足：传输性能上无法与二层，三层方案相比
flannel
service特性
1.以service暴露服务
2.service是k8s云应用的基本构建单元
3.service通过pod label 以及label selector 与pod（endpoint）自动建立关联
4.service会将来自客户端的请求流量自动负载均衡到后面的endpoints上面
5.service网络： cluserIP：k8s集群赋予 每个service在集群内部不便的ip地址
6.所有的service的cluster的clusterIP地址组成“虚拟网络”
7.使用Nodeport 将服务暴露到外部
8.外部请求 ->Node IP :Nodeport ->ClusterIP:Port ->Container:TargetPort
9.service网络的实现者：kube-proxy
10.kube-proxy 是以daemonset pod的形式运行在集群内的各个节点上
11.kube-proxy 通过iptables实现nodepod到集群内部的ServicePort再到 Pod中 container target port 的流量转发的
12.kube-proxy 通过iptables实现service流量转发的负载均衡
基于iptables的流量转发和负载均衡实现
1.kube-proxy监听服务和断点的变化设定和更新iptables的规则
k8s volume
1.volume：生命周期和其附着的Pod相同 ，可以在pod内的多个容器之间共享
2.k8s的volume本质上是一个目录
3.要使用volume，需要为pod指定spec.volume字段以及将它挂载到容器的位置spec.containers.volumeMount字段
4.支持多种volumeType： cephfs ,configmap ,hostpath ,nfs ,rbd, secret ,local,emptyDir等
PersistentVolume(PV)
1.PV 是集群中的资源，可以把PV看成是volume plugin的插件
2.PV的生命周期独立于pod
3.PV对象封装了底层存储卷的实现细节（cephfs，NFS）
4.PV的访问模式
{ReadWriteOnce , ReadOnlyMany，ReadWriteMany – cephfs}
PVC
PVC 是对PV的大小，访问方式的请求
绑定：PVC将与PV资源一一绑定
使用：像volume一样使用
storageClass
按照class匹配PV
动态PV供给
PV的状态和回收策略：
状态：Available/Bound/Released/Failed
回收策略： Retain/Recycle/Delete
api-server的安全模型
1.传输安全 TLS ：6443
2.身份验证 ： 普通用户 还是ServiceAccount
关注API请求的Header
目标：身份验证，识别出请求所代表的的k8s users信息
验证策略：支持client cretificates ，bearer tokens ，http basic auth以及 authenticating proxy
结果：通过身份验证的请求会被附加上一些身份信息属性，包括username，uid，groups以及一 些对授权环境有用的信息
3.授权，针对身份验证的用户/租户特定授权
4.准入控制（Admission Control）
5.apiserver的非安全端口是供测试使用 --insecure-port
6.APIserver的安全端口（–secure-port=6443）
7.内外的所有与api-server的交互都通过安全端口交互
k8s中的User
包括：Normal User和ServiceAccount两种
Normal User：k8s中没有任何对象可以用来表示Normal User
ServiceAccount：由k8s管理，用户pod访问 apiserver的“user”
匿名请求：username - system：anonymous , group-system:unauthenticated
ServiceAccount
1.k8s创建，使用签名bearer token对请求进行验证
2.组成：ServiceAccount ->{name，namespace，secret} ->{ca.crt,namespaces ,token}
3.secret对象自动挂载到Pod内/var/run/secrets/kubernetes.io/serviceaccount路径下面
api-server授权
根据请求信息和授权策略判断请求是否具有操作目标对象的权限
1.支持多种授权模块 ABAC，RBAC ，NODE ，WEBHOOK
2.启动授权模块：----authorization-mode=xx,yy
3.开启多种授权模块时，采用短路授权方式
RBAC访问控制模型
1.k8s1.6版本之后使用该模型
2.rbac的操作对象 subjects{dev ，ops，process} API resources{configMaps ,Pod, services,Autoscaler,secrets ,pv ,replicaset ,namespace， Daemonset ，cronjob
，job PVC nodes} Operations{ list ,create ,delete ,get patch ,watch}
3.通过Role 和RoleBinding 实现了RBAC中三类元素的映射连接