k8s_day02_01
apiserver 是整个k8s 系统的总线 ，是整个集群中唯一一个能存集群状态数据的位置。 但是apiserver 本身并不存，而是交给etcd 存储了。 所以etcd 在生产环境要做分布式冗余高可用，etcd 是基于go 语言、raft 协议研发的 强一致性分布式 的轻量级kv 存储系统
分布式、强一致的系统在协同时可能会发生脑裂，因此为了避免脑裂，集群的节点一般是奇数个，所以etcd 最少3个节点。因为apiserver 与etcd 是通过https 协议通信的 ，相当于apiserver 是无状态的，apiserver 做冗余就不必要和ectd 节点数量保持一致取奇数个，一般2个就够了，当然这也取决于我们的业务系统。apiserver 本质是https 服务， 监听在6443 端口，当api有多个时 , 客户端选择任意一个都行，所以可以把api 防止负载均衡器上，但是负载均衡器也可能单点失败，所以可以再配keepalived。nginx 用4层负载就行
而对于后端的server ,发生故障时，只要nginx 能探测到自己健康状态，并且摘除即可。
关于状态健康性检测，有2种，主动（AH）和被动（PH）检查
对于PH，通常叫做故障探测 或者叫异常值探测。nginx 做的探测 多数都是主动的，nginx 向后端发送请求，如果得到正常响应，就算健康。而被动检查 主要是观测 流量是否正常进行，如根据正常流量的响应码，是200还是502 判断。 还有就是根据相应时长，时间过长 大于正常平均时间就算有问题
controller manager 是控制器管理器，实现的作用是真正意义上是让k8s 所有功能得以实现的控制中心，k8s 有一个特点就是把运维日常工作代码化 ，代码化的集成位置就在controller 中。controller manager 中包含多个controller程序，把他们单个的controller 打包在一起成为一个组件，我们把它称为manager。
每个controller内部都有一个叫controller loop 的控制循环，这个死循环 会一直监视着 k8s 上所管理的那个对象的数据，比如pod数量，一旦不满足就会增减。
Scheduler 没有太大作用，除了调度，主要是调度Pod[现在IT架构，都讲究以应用为中心] ，k8s 的核心作用就算运行应用。Scheduler 会时刻关注每个节点上的资源可用量， 以及能为了更好运行这个应用所需要的运行环境，让二者做最佳匹配。当然如果最佳匹配的节点不止一个，如何选择呢？ 至上而下随便选一个就行。当然也可以选择一个合适的节点调度存储卷node 的主要作用就是为了运行Pod, node 的三个组件 :
kubelet ，是 整个apiserver 或者控制节点的 运行在每一个工作节点的agent，控制节点的大多数任务都是kebelet 执行的。所以可以认为控制平面派出到每一个节点上的 去执行控制平面所需要执行的任务，尤其像是创建删除pod 都是kebelet 完成的。也就意味着调度器调度完了， kubelet 就会知道这是调度到自己机器上的，它负责把创建容器的配置拿过来，在本机上调用container engine,如dockers ，
kube-proxy ：
service 就是由 kube-proxy在每个主机上生成的iptables 或者ipvs 规则。为什么service 能调度后端的pod呢， 创建的每一个service 都存到api server 上了 ，只要是创建或删除service 的操作， kube-proxy 就会在对应的节点上生成一些iptables规则，以便本地的pod能被负责均衡的规则所调度。service 内部用的是一种叫random 的算法，把请求随机分配到pod上。当然也可以用ipvs, ipvs支持更多的算法，sh 、dh、rr、wrr、wlc 等等。虽然说k8s 未必对ipvs中的每种算法都支持，但是好在多余iptables 的只有一个random 算法。二 、如果k8s 中跑了太多的service ,iptables 规则将会巨多，上万条，性能就会大受影响，但ipvs 就不会。
kube-proxy 就是一个确保 分散运行在各个节点的pod能够被正常调度一个daemon 守护进程
docker
运维工程师的三大核心职能：故障管理、资源管理、变更管理 k8s 对这些都有涉及：
- 故障管理： k8s 要部署日志分析展示系统用于容器排障
- 资源管理： 需要部署基础设施服务 kube-dns ,kubeadm启动时 会自动帮你运行一个附件 coredns
k8s 依赖的重要附件
Add-ons
- kubedns： coredns k8s内部使用的域名解析系统可以统称为 kubedns
- dashboard, web ui: 可以通过网页创建pod service，但是这个ui 目前不是特别好用而且我们特别依赖它😂
- 监控系统：Prometheus cncf 毕业的第二个项目 本身也是用go 写的
- 集群日志系统：
ElastichSearch ,ElastichSearch 本身并不收集日志，而是借助客户端收集工具 Filebeat/Fluented/fluent-bit等等, 其实日志收集器做起来是很简单的，大公司为了装逼都自己开发 ，日志展示系统 叫kibana ，这套完整的系统就叫EFK
k8s 为什么不用logstah ，是因为，logstash用的是一种叫 JRuby的语言开发【ruby是一种很小众的开发语言，类似csharp。python 的编译器是用C 开发的，所以python 可以叫做‘cpythjon’ 所以Jruby 是基于java 开发的，filebeat 收集日志只要占用大概2M内存，而logstash 需要占用2G，logstah 太吃资源显得太重量级，不适合在容器中收集日志】
- 除了EFK外，第二种解决方案就是LOKI 。洛基， 是仿照普罗米修斯构建的一套日志收集系统，轻量级，是云原生应用。虽然功能没有EFK 多。它的日志展示系统就是Granfana
- Ingress Controller:
ingress 表示入站的意思。 k8s 内部可以愉快的交流，但是当我们想接入外部的流量时，可以使用node port 类型的service 。每一个nodeport 类型的service 就是相当于在集群的边界上挖了一个洞，作为集群管理者，很难知道哪里挖了洞，除非把所有的nodeport 类型的service 找出来。现在大多应用层都是走的https/hhtp 协议，为了方便统一管理，可以nginx 或者envoy 之类的应用做反向代理 来进行这些‘缺口/洞’。 Ingress Controller 就起着类似的功能 ，叫做 入站流量管理器，所有入站流量，都必须经过ingress 进行分派到后面需要与外部通讯的service - 除了上面之外的附件还有千千万，那就按需部署了 ，如Jenkins
==iaas : 按需创建主机 ==
paas: 按需开发并且部署程序 ,所以为了运行业务应用，可能还需要部署其他的插件
控制平面组件 和 kubelet 是 k8s 的 非常重要组件，如果被入侵或者流量劫持了，会带来灾难性后果，所以组件间的安全通信非常重要，所以k8s 的组件都是基于https 协议进行的，ks 的一套系统中需要3个ca
- 第一套 etcdca ,etcd 本身既支持http 又支持https, 为了避免被破环， 做了peer的通信认证，点对点的认证，所以用https
- apiserver 肯定也需要一套ca 叫错kubernates ca, 用于给apiserver 的客户端和服务端各发证书
【scheduler 、controller、proxy、kubectl 、kubelet】 都需要客户端证书， apiserver 要服务端证书
它们彼此之间是双向认证的，kubelet连接到apiserver后 ， 要验证它的域名和证书保持一致，反之apisever也要验证kubelet的身份信息 简称 mtls 【mute TLS 】
如果手动部署k8s ,需要自己去建立这些证书密钥之类的，超麻烦。现在用的是kubeadm 部署的， kubeadm 已经GA ，可以在生产、和测试环境中使用。GA 叫做 genera availability 公共可用 。早2年，kubeadm 没有GA 是不敢在生产环境中部署的 ，用部署工具叫做github 上kubeeaz 的ansibe工具部署的，虽然部署效果一样。但是这个工具是k8s生态之外的一个工具，无法参与到k8s内生身的很多重要环节之中,而kubeadm 是ks SIG 【special instresting Groups 特殊兴趣小组】 提供的
- front-proxy-ca 聚合器 和扩展 apiserver时用到的
- 其实还有一个SA ，它不是证书，而是一个公钥私钥对
k8s 集群部署 和运行模型：3种
- 二进制程序： 各个组件以二进制程序或rpm包手动管理
- pod：
- static pod 静态pod
- pod ： 常规pod 、控制器管理下的pod
如图所示： 3种方式的附件都是 以pod 方式运行
第一种： master 、node 的所有组件 都可以以二进制程序部署的（左下第一个长方形图，cni flannel 除外），所有组件依靠init script 或者systenmd 管理
第二种： master 和node 的组件中，kubelet 和docker 仍然以二进制方式靠 init script 或者systenmd 管理(中间的正方形图)，其他组件仍然以Pod方式运行 ，但是 master中的这些pod 是不受控制器管理的，而是受kubelet 直接借助一个叫配置清单的文件（manifest）管理 ， kubelet 会监视某个目录是否有某个应用的清单，如果有就创建起来，而且只要发现那个pod 不在会自动创建起来，这叫静态pod。 以kubeadm 为代表
第三种： 相对于第二种来说 ，区别就是 ， master上控制平面组件pod 是受控于自己专门的控制器管理，而不是kubelet. 应用场景就是共有云的kaas 服务 （阿里云亚马逊） ，只要你提供 master 和node 的数量，就能拉起一个集群，因为把拉起的过程全部代码化了，缺点就是贵，以动态pod的方式来运行这些控制组件pod
如果用kubeadm 来管理k8s ，它做不到以下事：它不会帮你创建主机，不会帮你管理主机，所以对于Laye1 基础设施层它管理不到 ，无法通过api 创建主机
kubeadm 主要在第二层实现了2个功能 bootstrapping(拉起引导）一个集群 ，并且提供一个基本的功能api
kubeadm 除了提供了coredns ，在第三层，并没有提供其他的附件
下图蓝色的部分是kubeadm 可以完成的任务，运行蓝色组件。（通常不认为kube-proxy是附件，但是有些机构认为）
k8s 没有实现网络插件，太复杂了，而是交给专业的网络公司。只留了一个容器网络接口
CNI：
Container Network Interface。 目前CNI 的解决方案 海了去，有几十种之多，但目前最流行的只有两个
- flannel
coreos 这家组织研发的，只实现了网络，而没有实现网络策略 , 简单易学 , 叠加和承载模型都支持, 性能也不差 hostgw 的机制 ,支持directRouting Vxlan 三种 - Project Calico
既实现了网络，又实现了网络策略 , 生产环境使用居多,而且支持BGP协议的underlay network 性能更强大 - Cannel:
网络功能用flannel 实现 , 策略用Calico 实现 , 现在已经废弃不再更新(因为作者后发现 相当于又实现了一遍Calico)
CNI通常要求组件有２个功能：第一网络解决方案,underlay 和overlay 都行. 第二, 网络策略:控制通信的 ,两个pod之间能不能通信 k8s并没有做任何限制,只要能部署就能通信.但是 如果是一个多租户环境 ,如公司里有多个团队,每个团队要独立隔离, 可认为每个团队就是一个租户,租户与租户之间要隔离, 但是就算是用名称空间隔离 起来, A租户去访问 B租户是没有任何问题的，
CRI : R untime 容器运行时
CSI: Storage 存储
flannel 是如何工作的?
节点网络: 各个物理节点 的网卡接口 真正通信的地方(无论是叠加还是承载网络模型 都必须有). 可以认为是是虚拟机Ip 所组成的, 172.29…0.0/16 自己规划
Pod 网络: flannel 用的是10.244.0.0/16 网段 , 会给每个物理节点分配一个子网 如10.244.1.0/24 .这个可以自己设置划分,若想运行最大数量pod,可以网段设置为8位,如10.0.0.0/8…通常一个节点主机 运行256 容器撑死 , 所以每个主机可以分配到一个C类子网(24 位掩码,1个255). 这样就可以支持256*256 台主机 可以自己选择,适配网络插件默认设定 会减少很多麻烦, 除非我们有特殊需要
service 网络: 默认flannel 用的是 10.96.0.0/12 地址 . 所以service 可用的地址为 10.96.0.1 ~10.111.255.255
[root@master01 ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
demoapp ClusterIP 10.107.176.51 <none> 80/TCP 2d7h
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2d9h
[root@master01 ~]#service 是一个虚假网络 , service 地址不会设置在任何网卡或网络接口上,只是会出现在service相关的iptables或者ipvs 规则中做为服务访问入口或者端点 , 也会出现在dns解析记录中把service对应名称解析为对应ip service 网络 是由kube-proxy 管理 , 在哪里指定的呢,用 kubeadm 部署时, service-cidr参数 指定
–service-cidr string Use alternative range of IP address for service VIPs. (default “10.96.0.0/12”)
kubeadm 拉起一个集群的流程
kubecofig 介绍
[root@master01 ~]# cd /etc/kubernetes/
[root@master01 kubernetes]# ls
admin.conf controller-manager.conf kubelet.conf manifests pki scheduler.conf
[root@master01 kubernetes]#kubecofig 就是/etc/kubernetes/目录下的文件
[root@master01 kubernetes]# cat admin.conf
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZyT3NqRERsYWtLQgpjcEJmbTZFbjRRSERPVE03aWxHdWZNck9OZ2MrbFpUZlgvY3B1elVvOUxwS0Z6eE5pT2RiNUFzeCtiTmk1bFg0CjQvQjNMbnBqN2tmZzF4bG1EY1Q1VVllMjhsNnRZQUxCQmszTAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
server: https://kubeapi.magedu.com:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURFekNDQWZ1Z0F3SUJBZ0lJT0F5T2o1c2NRMk13RFFZSktvWklnQwpR2kzWEZ5d09ZZVBwYXdYMGZOdXlGNE5BdFpmWHYvS3JRY1hiY1pQazU0eWsKcjRjbXVmSXJGb1EwbWNSSkNyazFBWU1qMmVOQUJjcz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcFFJQkFBS0NBUUVBNlB3cnFoK0lLeFRnWkliczJEZndRT1bHVHVFdEYWh6WXR3MUdwL05EK0dNSE9yLwpHUFNjVDlEcjdoVWdza29BMWVTM2owbS9hRjlQQVpCK0NKOGR3amJKOXVlOGhyY3YrRU9LQjdzPQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=
[root@master01 kubernetes]#主要就是集群的地址端口 , 集群的名称, 访问集群时用的用户名称以及相关证书，私钥信息.
为什么要写在配置文件中?https 是无状态协议, 每一次访问都要认证 ,不这样就要以命令行的方式指定认证信息. 特麻烦. admin.conf 是 kubectl 客户端以超级管理员(相当于root)的身份连接到apiserver 上时使用的
controller-manager.conf : 控制平面组件除了 apiserver 都是apiserver的客户端,都需要认证 , scheduler.conf也是同理
真正的证书都在/etc/kubernetes/pki/ 目录下
[root@master01 kubernetes]# ll /etc/kubernetes/pki/
total 56
-rw-r--r-- 1 root root 1298 Nov 25 00:26 apiserver.crt
-rw-r--r-- 1 root root 1135 Nov 25 00:26 apiserver-etcd-client.crt
-rw------- 1 root root 1675 Nov 25 00:26 apiserver-etcd-client.key
-rw------- 1 root root 1679 Nov 25 00:26 apiserver.key
-rw-r--r-- 1 root root 1143 Nov 25 00:26 apiserver-kubelet-client.crt
-rw------- 1 root root 1675 Nov 25 00:26 apiserver-kubelet-client.key
-rw-r--r-- 1 root root 1066 Nov 25 00:26 ca.crt
-rw------- 1 root root 1679 Nov 25 00:26 ca.key
drwxr-xr-x 2 root root 162 Nov 25 00:26 etcd
-rw-r--r-- 1 root root 1078 Nov 25 00:26 front-proxy-ca.crt
-rw------- 1 root root 1679 Nov 25 00:26 front-proxy-ca.key
-rw-r--r-- 1 root root 1103 Nov 25 00:26 front-proxy-client.crt
-rw------- 1 root root 1679 Nov 25 00:26 front-proxy-client.key
-rw------- 1 root root 1675 Nov 25 00:26 sa.key
-rw------- 1 root root 451 Nov 25 00:26 sa.pub
[root@master01 kubernetes]#静态pod 清单文件
[root@master01 kubernetes]# ll /etc/kubernetes/manifests/
total 16
-rw------- 1 root root 2118 Nov 25 00:26 etcd.yaml
-rw------- 1 root root 3176 Nov 25 00:26 kube-apiserver.yaml
-rw------- 1 root root 2858 Nov 25 00:26 kube-controller-manager.yaml
-rw------- 1 root root 1413 Nov 25 00:26 kube-scheduler.yaml
[root@master01 kubernetes]#Taint and the label master : 给master 节点打污点,污点是高级调度策略的一种 ,pod 不会调度到有污点的机器上,所以新建的pod 不会在master 上
Bootstrap Token: 生成一个引导令牌 : 也就是生成一个随机字符串当密码. 这个令牌是会过期的,且符合CA的签名
kubeadm join kubeapi.magedu.com:6443 --token sjh4s0.lsj3y7swfjpf9d2g
–discovery-token-ca-cert-hash sha256:f65cce015ac254b3e7c3a0cac59ac031079d9c31ffac12f31940a57d15c30764
