目录
1.了解密码学的两个概念
- 对称加密，用用同样的密钥对数据进行加解密。
- 非对称加密，加密和解密的密钥不一样，加密的密钥称为公钥，大家都可以知道，解密的密钥称为私钥。
- 单向认证
网络通讯是双向的，但是安全认证不一定都是双向。大多数情况下可能都是单向的，只需要客户端确认服务端是可靠的，而服务端不管客户端是否可靠。即客户端，比如浏览器会验证服务端证书，服务端不需要客户端证书。
- 双向认证
双向认证相对于单向认证，即客户端需要确认服务端是否可信，服务端也需要确认客户端是否可信。双方都要验证对方的证书。
HTTPS：起初是因为HTTP在传输数据时使用的是明文（虽然说POST提交的数据时放在报体里看不到的，但是还是可以通过抓包 工具窃取到）是不安全的，为了解决这一隐患网景公司推出了SSL安全套接字协议层，SSL是基于HTTP之下TCP之上的一个协议 层，是基于HTTP标准并对TCP传输数据时进行加密，所以HPPTS是HTTP+SSL/TCP的简称。在SSL更新到3.0时，IETF对SSL3.0 进行了标准化，并添加了少数机制(但是几乎和SSL3.0无差异)，标准化后的IETF更名为TLS1.0(Transport Layer Security 安全传 输层协议)，可以说TLS就是SSL的新版本3.1，
SSL/TLS：（使用对称加密算法的过程）
第一次通信的时候，客户端使用公钥加密了一个密钥，将密文的密钥发送到服务器，服务器通过自己的私钥就可以解开密文得到密钥。接下来客户端使用改密钥来加密要发送的数据，服务器因为之前收到了密钥，所以可以通过这个密钥进行解密数据，这样就是用对称加密的算法完成了，对称加密的算法的性能比非对称的好。这样的话还是存在问题，服务器给客户端返回公钥的过程被黑客截获，篡改公钥发给客户端，然后客户端加密后数据再被截获就完了。
现在解决这个问题的办法就是使用CA证书加密，服务器给客户端返回公钥的时候，客户端拿到公钥就会去CA询问，这个公钥是不是合法的。如果访问网站，使用https出现红色的警告，那么这个证书就不是CA认证的，一般是自己生成的。
1.服务器向CA机构获取证书（假设这个证书伪造不了），当浏览器首次请求服务器的时候，服务器返回证书给浏览器。（证书包含：公钥+申请者与颁发者的相关信息+签名）
2.浏览器得到证书后，开始验证证书的相关信息，证书有效（没过期等）。（验证过程，比较复杂，详见上文）。
3.验证完证书后，如果证书有效，客户端是生成一个随机数，然后用证书中的公钥进行加密，加密后，发送给服务器，服务器用私钥进行解密，得到随机数。之后双方便开始用该随机数作为钥匙，对要传递的数据进行加密、解密。
2.K8S认证方式
- 客户端证书认证（TLS双向认证）
k8s集群给自己的每个组件都颁发了ca证书，包括kubectl，然后kubectl 和k8s组件互相验证证书。看看是不是颁发。
- Bearer Token
- ServiceAccount（namespace,token,ca）用于集群内部之间的认证
3.k8s鉴权机制
4.k8s的授权方式：
授权也有三种方式，ABAC，WebHook,RBAC,前两种不掌握，因为官方默认用的第三种。用户又两种User和ServiceAccount，对应的权限也有两种。
role的设计：
角色如何和用户绑定呢？通过RoleBinding，角色在namespace下生效，当然有一个跨命名空间调用的角色，ClusterRole.
5.准入控制：
认证授权完了以后还有最后一道流程，准入控制，这个流程就是一系列的小代码块，可以理解为java中一系列的过滤器。
6.安装方式对比（官方）
Kubeadm的按转包给方式：
安装的地址链接：
https://gitee.com/xiebingmeng/kubernetes-ha-kubeadm?_from=gitee_search
7.滚动部署的过程：
我们所管理的层面在Deployment上，RS和pPOD不需要们去管理的。当重新更新的时候会新Deployment会重新起一个RS，然后根据新的镜像起一个POD，POD健康检查通过后，然后旧的RS删除掉原来的POD，然后同样的方式更新第二个。
Service与Lable:lable可以打在很多东西上，比如POD可以打标签，NODE可以打标签，Deployment也可以打标签。
