k8s学习笔记

Brog架构
访问方式：浏览器 命令行 文件

borgmaster：请求分发
防止单节点故障 -> 多个副本
高可用集群->单数->投票
存在一个键值对数据库：paxos
scheduler将调度结果存入paxos数据库，borglet实时监测paxos数据库，如果发现自己的请求，则取出处理
borglet：提供服务

scheduler：调度器

k8s架构

访问方式：kubectl，webui

master服务器：
scheduler：调度器，将调度结果提供给api server，api server将内容写入etcd。
replication controller RC：控制副本数量,
api server：全部服务访问入口
为减轻压力，各个组件会产生一定缓存

node节点：
kubelet：c（容器），r(运行环境)，i（接口）->docker的表现形式
和docker交互，操作docker，生成对应容器，维持pod的生命周期。
kubeproxy：负载均衡，pod之间访问。默认操作是设置防火墙，完成pod映射，新版本支持ipvs/iptables，ls组件。
pod：
container：eg：docker 一种容器引擎的实现方案

etcd：可信赖，分布式，键值对数据库，持久化。
天生支持集群化（eg：mysql，如果想支持集群化，需要增加一些中间件）
v2 ：写入内容
v3：本地卷持久化，关机后可从本地磁盘恢复 k8s1.11即以前 不支持v3

etcd：采用http协议，进行c/s（k8s一样）
raft：存储全部信息，进行信息读写
wal：读写日志，如果相对数据进行更改，先生成日志，定时对全部日志进行整合备份生成完整日志。实时将日志和数据写入本地磁盘，进行持久化。
entry：
shapshot：

CoreDns：为集群中的svc创建域名ip的对应关系解析
dashboard；给k8s集群提供一个b/s结果访问体系
ingress controller：官方实现四层代理，ingress 提供七层代理，支持主机名，域名的负载均衡
fedetation：提供一个跨集群中心多k8s统一管理
Prometheus：监控
efk/elk：日志分析介入

pod：自主式的pod
控制器管理的pod

多个容器独立存在，有自己的ip port 挂载卷，网络站等，在k8s迁移时很麻烦，需要重新配置ip等内容，除非将两个镜像放在一个容器下或两个容器使用一个网络站
定义一个pod ->启动一个容器pause（只要有容器，就要启动）->一个pod中可有多个容器，多个容器共用pause的网络站，挂载卷，->通过一个pod中 容器端口不得重复

replication controller RC：确保pod的副本数
replicaset RS：等于RC 支持集合式selector -> 创建pod时会为其打标签，可根据标签删除
deployment：管理RS,无需担心和其他机制不兼容的问题（RS不支持滚动更新，deployment支持）
滚动更新时，创建新的rs，由rs创建node
控制器=
rc和rs：,deployment：,daemonset, statefulset, job/cronjob, hpa

replication controller RC：确保pod的副本数
replicaset RS：等于RC 支持集合式selector -> 创建pod时会为其打标签，可根据标签删除
deployment：管理RS,无需担心和其他机制不兼容的问题（RS不支持滚动更新，deployment支持）
为pod和rs提供声明式方法
定义deployment，创建新的rs，由rs创建node
滚动更新，扩容缩容，暂停继续deployment
声明式 deployment apply
命名式 rs create

HPA:pod平滑扩展 仅适用于rs+deployment；根据pod的cpu利用率扩容
一个对象 需要被定义（cpu利用率为多少，pod个数为多少 。。。）
vlalpha版本中可根据内存和用户自定义的阈值进行扩容/缩减

无状态 docker，apache
有状态：mysql，mogoDB

statefullset：进行有状态服务：稳定的持久化存储+稳定的网络标示+有序部署（按顺序部署回收）
daemonset：确保全部或一些（污点node不被调度）node上运行一个pod节点(只能一个)，node加入集群时 会生成pod， node移除时，会删除pod
删除daemonset，会删除其创建的全部pod
job：批处理任务 仅执行一次，保证批处理任务的一个或多个pod成功结束
将任务放于pod，将pod存入job运行，pod可多次利用，
job若判断脚本异常退出，则重新开始运行，确保成功结束
job可要求脚本正常退出n次才可结束。
cronjob：周期性在指定时间运行，指定时间点只运行一次
在特定时间循环创建job实现

k8s网络模型：所以pod都在一个可以直接连通的扁平的网络空间

同一个pod中的多个容器：lo（共享同一个linux协议栈，pause）

各个pod之间：overlay NetWORK，通过dokcer0网桥之间转发

pod和service之间：各节点之间的iptables + lvs
flannel：让集群中不同节点主机创建的docker容器具有全集群唯一的虚拟ip地址，在ip地址之间创建一个覆盖网络（overlay NetWORK）
通过覆盖网络，将数据包传递到目标容器。 路由转发，隧道
建立一个name = flanneld的守护进程，
flanneld：监听转发数据包的服务端口，存在路由表记录（从etcd获取写入当前主机）
开启网桥 flannel0，收集docker0转发出来的数据包，docker0分配ip到pod上
将可以分配的网段，以及ip分配结果插入etcd
监控etcd中每个pod的实际ip地址。在内存中维护pod节点的路由表

====资源清单=
名称空间级别
工作负载型资源：pod rs deployment statefulset daemonset job cronjob
服务发现及负载均衡型资源：service ingress
配置与存储型资源：volume（存储卷）csi（容器存储接口，扩展第三方存储卷）
特殊类型存储卷：configMap，secret，downwardapi（把外部环境中的信息输出给容器）
集群级别：全部命名空间都可以看到
namespace，node，role，clusterRole、roleBinding，clusterRoleBinding
元数据级别：根据一些指标进行操作，如平滑扩展时内存，cpu的使用限制，pod模板等
HPA，podTemplate，limitRange

k8s全部内容都抽象为资源，资源实例化之后为对象

=容器生命周期====
kubectl调用api接口 -》api调度kubelet（etcd完成存储） -》kubelet执行cri -》容器环境初始化（创建pause -》pod生命周期）
pod生命周期：init c（初始化容器，0个或多个 eg：某pod需要xx文件才可以运行，此时则在创建文件，上一个initc成功结束，才能开启下一个initc，正常退出结果为0，如果异常退出，结果非0，则根据策略进行重新运行或结束。init容器总是运行到成功完成为止（默认重启（全部init容器都要重启，意味着init容器多次运行结果一致）,达到重启最大次数为止））
main c（启动时运行start， 结束时运行stop）
在容器运行xx秒之后进行readiness和liveness探测（时间可配置）
readiness（就绪检测）：转变状态为running/ready
liveness（存活检测）：出错时根据策略重启/结束
mianc会影响pod的生命周期，initc不会，所以initc异常退出时，需要对pod进行流程处理

init c：
在网络和数据卷初始化（在pause中）之后启动，
初始化时，pod状态为pending，initializing=true，init容器端口不会在service中聚集
只能修改init容器的image字段，修改后会重启pod，修改其他字段不会生效
initc，类似于普通pod ，具有应用容器的全部字段除readiness和liveness，因为initc只有completion和readiness两种状态，如果有则不生效
在pod中每一个app和init容器的名称唯一，同一组initc的端口可以一致
可以包含并运行实用工具，但不建议（ eg：某pod需要xx文件/数据才可以运行，将这些文件/数据的创建/梳理工具存入initc）
可包含使用工具和定制化代码安装，但不能出现在应用程序镜像中，eg：创建镜像无需from另一个镜像，只需要在安装过程中使用类似sed，awk，dig等工具
将代码分离出创建和部署（长期运行提供服务）两部分，将创建部分放入initc
initc可以使用linux namespace，所以相对于应用程序容器，具有不同的文件系统视图，eg：initc具有secret权限， 而应用程序容器不行；应用程序容器在初始化时需要某个文件的权限，如果给给他，他在整个运行过程均可进行处理，给initc，则只有一开始可以
init c在应用程序容器启动之前运行完成，而应用程序容器之间可以并行执行，所以initc提供一种阻塞或延迟应用程序启动的方案。
eg：一个pod中有两个容器 ab，a先启动，b再启动，顺序是 initcA -》initcB + maincA -》maincA +maincB或maincB，可能b容器启动好的时候a容器还未启动完成，则出错-》退出，重启，
initcB 探测maincA是否启动完成，完成再开始运行

探针===
kubelet对容器执行的定期检测
execAction：在容器内执行指定命令，结果为0认为诊断成功
TCPSocketAction：对指定容器的ip port进行tcp检查
HTTPGetAction：对指定容器的ip port进行http get请求，如果响应码大于等于200 & 小于100，认为诊断成功

探测结果：成功，失败、未知

探测方案：
readiness（就绪检测）：若失败，端点控制器将从pod匹配的所有service端点中删除该pod的ip地址，初始延迟之前的就绪状态默认为failure。若容器不存在就绪探测，默认状态为success
liveness（存活检测）：若失败，则会杀死容器，根据策略，重启/结束。若容器不存在存活探测，默认状态为success

状态：
pending 挂起：pod已被k8s系统接受，但又一个或多个容器镜像尚未被创建，等待：调度pod，下载网络镜像。。。
running 运行：pod已被绑定到一个节点，pod的所有容器都已被创建，至少有一个容器正在执行或处于启动/重启状态（所以running状态的节点不一定可以访问）
success 成功：pod中全部容器都已经成功结束，且不会重启
failure 失败：pod中的全部容器终止&至少一个容器异常终止
unknown 未知：一般是与pod所在主机通信失败

=service=
通过label selector 匹配一组pod 对外提供服务访问
每个svc可理解为一个微服务

概念：根据标签查找（实时）pod 将合适的pod写入svc的记录中，每次svc接受到请求，轮询pod
特点：只有四层负载能力 根据port+ip转发 -》+ingress转为七层
分类：
clusterip：内部访问的ip（默认类型）
nodeport：在clusterip基础上，为svc在每台机器上绑定一个端口，外部访问，通过nodeport访问服务
loadbalancer：在nodeport基础上，借助cloud provider，创建外部负载均衡器，将请求转发到nodeport
nodeport中，svc暴露端口，然后需要将ip+port注册到某一个负载均衡机器上使用。
loadbalancer中，会自动生成负载均衡机器，暴露相关服务端口，并将其写入负载均衡机器中（自动化），需要云供应商
externalName：在内部引用外部服务，定义一个svc，将外部服务注册，内部调用svc即可，便于管理，不存在proxy被创建

kubeproxy 监控pod，根据标签匹配，将pod信息写入iptables的规则中去，
确定pod信息被写入svc的endpoint中
访问时 通过iptables导入到指定pod
api server 通过监控kubeproxy 监控端点和服务（更新）

iptables通过nat等技术将virtualip的流量转入endpoint中

不使用dns进行负载均衡，因为dns会在主机缓存，则不再负载均衡

代理模式=
userspace：client -》iptables-》kubeproxy -》pod（kubeproxy压力大）
api-》kubeproxy
iptables：client -》iptables-》pod（更快，默认）
api-》kubeproxy-》iptables
ipvs：client -》ipvs -》pod
api-》kubeproxy-》ipvs

ipvs需要大量算法支持，如果算法不存在 则会退回到iptables状态

用户向apiservice发送创建svc的请求，api将数据存入etcd
kubeproxy 监测etcd的变化，并将内容写入iptables，
每个节点有自己的kubeproxy

存储模式
configmap：存储配置文件，
secret：
service account(SA):用于访问api，由k8s自动创建且自动挂载到pod的指定目录下
opaque：存储密码密钥 base64加密
dockerconfigjson：存储docker信息 eg：仓库认证信息（用户名+密码）
volume：给pod提供共享存储卷的能力
kubelet重启 数据会消失，
卷的生命与封装其的pod相同，卷有多种类型，一个pod可以使用任意数量的卷

persistentVolume（PV）：持久卷
不同的存储 对应不同的存储卷

pvc：用户存储的请求

安装kubectl
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl

curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.19.3/bin/linux/amd64/kubectl
chmod +777 kubectl
mv /usr/local/java/jdk1.8.0_11/kubectl /usr/local/bin/kubectl

[root@SZ-OFFICE2-172-20-52-31 bin]# kubectl version
Client Version: version.Info{Major:“1”, Minor:“14”, GitVersion:“v1.14.1”, GitCommit:“b7394102d6ef778017f2ca4046abbaa23b88c290”, GitTreeState:“clean”, BuildDate:“2019-04-08T17:11:31Z”, GoVersion:“go1.12.1”, Compiler:“gc”, Platform:“linux/amd64”}

wget https://storage.googleapis.com/kubernetes-helm/helm-v2.12.1-linux-amd64.tar.gz
tar -xf helm-v3.3.1-linux-amd64.tar.gz
mv helm …/
[root@SZ-OFFICE2-172-20-52-31 bin]# helm version
Client: &version.Version{SemVer:“v2.14.1”, GitCommit:“5270352a09c7e8b6e8c9593002a73535276507c0”, GitTreeState:“clean”}
vi ~/.kube/config

helm init

yum install go -y