巩固链接视频：
尚硅谷Kubernetes教程(K8s新版已上传，推荐观看)
https://www.bilibili.com/video/BV1w4411y7Go?p=1
重点截图
第四十八节
集群调度
Scheduler是k8s的调度器，主要任务是把定义的pod分配到集群的节点上
考虑因素：公平，资源高效利用，效率，灵活
scheluer是单独运行的程序，启动后一直监听API server获取'PodSpec.NodeName'为空的pod,对每个pod都会创建一个binding,表明该pod应该放在哪个节点上
调度过程
首先过滤掉不满足条件的节点，这个过程为predicate ---预选
PodFirsResources
PodFitsHost
PodFitsHostPorts
PodSelectorMatches
NoDiskConflict
其次通过对节点的优先级排序，这个过程为priorty ---优选排序
LeastRequestedPriority
BalancedResourceAllocation
ImageLocalityPriority
计算权重累加进行排序
最后选择优先级较高的节点来；如果任何一步出错，直接返回错误
第四十九节
node亲和性
pod.spec.nodeAffinity
preferredDuringSchedulingIgnoredDuringExecution: 软策略 requiredDuringSchedulingIgnoredDuringExecution: 硬策路
pod亲和性
pod.spec.podAffinity.podaffinity/podantiaffinity
preferredDuringSchedulingIgnoredDuringExecution: 软策略 requiredDuringSchedulingIgnoredDuringExecution: 硬策路
第五十一节
污点和容忍（Taint Toleration）
Taint的组成
使用kubectl taint 命令可以给某个Node节点设置污点，可以让Node拒绝pod的调度执行，甚至将node已经存在的pod驱离出去
污点的组成如下：key=value:effect
每个污点有一个key和value作为污点标签，其中value可以为空，effect描述污点的作用
当前taint effect支持如下三个选项：
NoSchedule 表示不会将pod调度到具有该污点的node上
PreferNoSchedule 尽量避免
NoExecute 不会调度该污点的node上，同时驱离node上已经存在的pod
kubectl taint nodes node名 key1=value1:NoExecute 立即驱离节点上的pod
kubectl taint nodes node名 key1=value1:NoExecute- 删除节点污点标签
tolerations:
其中key, vaule, effect 要与 Node 上设置的 taint 保持一致
operator 的值为 Exists 将会忽略value值
tolerationseconds 用于描述当Pod 需要被驱逐时可以在 Pod上继续保留的运行时间
1，当不指定 key ,值时，表示容忍所有的污点 key：
tolerations:
- operator: "Exists"
2，当不指定 effect 值时，表示容忍所有的污点作用
tolerations:
- key: "key"
operator: "Exists"
3，有多个Master 存在时，防止资源浪费，可以master节点如下设置
kubectl taint nodes node名 node-role.kubernetes.io/master-:PreferNoSchedule
第五十二节
pod固定节点调度
根据node名
spec:
nodeName: node名、或nodeIp
根据node标签选择
spec:
nodeSelector:
type:backend
节点创建标签
kubectl label node node名 type=backend
第五十三节
安全认证
k8s的安全机制基本就是围绕保护API Server来设计的，k8s使用
认证（Authentication）
Http Token认证 很长很复杂的字符创
Http Base认证 用户名+密码
最严格的Https证书认证 基于CA根证书签名的客户端身份认证方式（双向认证）
两种类型：
k8s组件对API Server的访问：kubectl,Controller Manager,Scheduler,kubelet,kube-proxy
k8s管理的pod对容器的访问：pod(dashborad也是pod形式运行)
安全性说明：
Controller Manager,Scheduler与API Server在同一台机器上,所以直接使用API Server的非安全端口访问 --insecure-bind-address=127.0.0.1
kubectl,kubelet,kube-proxy访问API Server就都需要证书进行HTTPS双向认证
证书颁发：
手动签发:通过K8s集群跟CA进行签发HTTPS证书
自动签发:kubelet首次访问API Server时，使用token做认证，通过后，Controller Manager会为kubelet生成一个证书，以后访问都是用证书做认证。
kubeconfig(root/.kube/目录下)
文件包含集群参数（CA证书，API Server地址），客户端参数（上面生成证书和私钥），集群context信息（集群名称，用户名）。k8s组件通过启动时指定不同的kubeconfig文件可以切换到不同的集群
ServiceAccount（SA）
pod中的容器访问API Server,因为pod的创建，销毁是动态的，所以要为它手动生成证书就不行，k8s使用了ServiceAccount解决pod访问API Server的认证问题
Secret与SA的关系
Secret:
一种是ServiceAccount的service-account-token
一种是用于保存用户自定义保密信息的Opaque
SA包含三部分：(默认在pod中的/run/secrets/kubernetes.io/serviceaccount/目录)
token
ca.crt
namespace（每个会有一个SA,如果pod创建时没有指定SA,就会使用pod所属的namespaces的SA）
第五十四节
鉴权（Authorization）
AlwaysDeny:拒绝一切，用于测试
AlwaysAllow:允许接受所有请求，若集群不需要授权流程，则可以采取该策略
ABAC(Attribute-Based Access Control):基于属性的访问，表示使用用户配置的授权规则对用户请求进行匹配和控制
Webbook:通过外部调用REST服务对用户进行授权
RBAC(Role-Based Access Control):基于角色的访问控制，现行默认规则（k8s 1.5引入）
优势：
对集群中的资源非资源均拥有完整的覆盖
整个RBAC完全由几个API对象完成，通其他API对象一样，可以用k8s或api进行操作
可以在运行时进行调整，无需重启API Server
RBAC引入4个新的顶级资源对象：
Role
RoleBinding
ClusterRole
ClusterRoleBinding
第五十六节 实践
linux创建用户：
useradd devuser
passwd devuser
cfssl 工具命令 证书工具
生成证书请求，证书私钥
设置集群参数
设置客户端认证参数
设置上下文参数
设置默认上下文
第五十七节
准入控制（AdmissionControl）来保证API Server的安全
认证-->鉴权（RBAC）-->准入控制
