kubernetes知识点

kubernetes优缺点
k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。
1、故障迁移：当某一个node节点关机或挂掉后，node节点上的服务会自动转移到另一个node节点上，这个过程所有服务不中断。这是docker或普通云主机是不能做到的
2、资源调度：当node节点上的cpu、内存不够用的时候，可以扩充node节点，新建的pod就会被kube-schedule调度到新扩充的node节点上
3、负载均衡：如果一个服务起动了多个容器，能够自动实现请求的负载均衡
4、资源隔离：每个命名空间只能看到对应的pod，互不干扰。
5、安全：不同角色有不同的权限，查看pod、删除pod等操作；RBAC认证增加了k8s的安全

一个kubernetes集群主要是由控制节点(master)、工作节点(node)构成，每个节点上都会安装不同的组件。
master：集群的控制平面，负责集群的决策 ( 管理 )
ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制
Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上
ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等
Etcd ：负责存储集群中各种资源对象的信息
node：集群的数据平面，负责为容器提供运行环境 ( 干活 )
Kubelet : 负责维护容器的生命周期，即通过控制docker，来创建、更新、销毁容器
KubeProxy : 负责提供集群内部的服务发现和负载均衡
Docker : 负责节点上容器的各种操作

以部署一个nginx服务来说明kubernetes系统各个组件调用关系：
1. 首先要明确，一旦kubernetes环境启动之后，master和node都会将自身的信息存储到etcd数据库中
2. 一个nginx服务的安装请求会首先被发送到master节点的apiServer组件
3. apiServer组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上
在此时，它会从etcd中读取各个node节点的信息，然后按照一定的算法进行选择，并将结果告知apiServer
4. apiServer调用controller-manager去调度Node节点安装nginx服务
5. kubelet接收到指令后，会通知docker，然后由docker来启动一个nginx的pod
pod是kubernetes的最小操作单元，容器必须跑在pod中至此，
6. 一个nginx服务就运行了，如果需要访问nginx，就需要通过kube-proxy来对pod产生访问的代理
这样，外界用户就可以访问集群中的nginx服务了


Master：集群控制节点，每个集群需要至少一个master节点负责集群的管控
Node：工作负载节点，由master分配容器到这些node工作节点上，然后node节点上的docker负责容器的运行
Pod：kubernetes的最小控制单元，容器都是运行在pod中的，一个pod中可以有1个或者多个容器
Controller：控制器，通过它来实现对pod的管理，比如启动pod、停止pod、伸缩pod的数量等等
Service：pod对外服务的统一入口，下面可以维护者同一类的多个pod
Label：标签，用于对pod进行分类，同一类pod会拥有相同的标签
NameSpace：命名空间，用来隔离pod的运行环境



pod：kubernetes最小资源单位，包含一个或多个容器
下面是Pod的资源清单：
apiVersion: v1 #必选，版本号，例如v1
kind: Pod       　 #必选，资源类型，例如 Pod
metadata:       　 #必选，元数据
name: string     #必选，Pod名称
namespace: string   #Pod所属的命名空间,默认为"default"
labels:       　　   #自定义标签列表
  - name: string     　          
spec:   #必选，Pod中容器的详细定义
containers:   #必选，Pod中容器列表
- name: string   #必选，容器名称
  image: string   #必选，容器的镜像名称
  imagePullPolicy: [ Always|Never|IfNotPresent ]  #获取镜像的策略
  command: [string]   #容器的启动命令列表，如不指定，使用打包时使用的启动命令
  args: [string]       #容器的启动命令参数列表
  workingDir: string   #容器的工作目录
  volumeMounts:       #挂载到容器内部的存储卷配置
  - name: string       #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
    mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符
    readOnly: boolean #是否为只读模式
  ports: #需要暴露的端口库号列表
  - name: string         #端口的名称
    containerPort: int   #容器需要监听的端口号
    hostPort: int       #容器所在主机需要监听的端口号，默认与Container相同
    protocol: string     #端口协议，支持TCP和UDP，默认TCP
  env:   #容器运行前需设置的环境变量列表
  - name: string   #环境变量名称
    value: string #环境变量的值
  resources: #资源限制和请求的设置
    limits:   #资源限制的设置
      cpu: string     #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
      memory: string   #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
    requests: #资源请求的设置
      cpu: string     #Cpu请求，容器启动的初始可用数量
      memory: string #内存请求,容器启动的初始可用数量
  lifecycle: #生命周期钩子
postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
  livenessProbe:   #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
    exec:       　 #对Pod容器内检查方式设置为exec方式
      command: [string]   #exec方式需要制定的命令或脚本
    httpGet:       #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
    tcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式
        port: number
      initialDelaySeconds: 0   #容器启动完成后首次探测的时间，单位为秒
      timeoutSeconds: 0   　　#对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
      periodSeconds: 0     　　 #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
restartPolicy: [Always | Never | OnFailure]  #Pod的重启策略
nodeName: <string> #设置NodeName表示将该Pod调度到指定到名称的node节点上
nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定
- name: string
hostNetwork: false   #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
volumes:   #在该pod上定义共享存储卷列表
- name: string     #共享存储卷名称 （volumes类型有很多种）
  emptyDir: {}       #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
  hostPath: string   #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
    path: string     　　         #Pod所在宿主机的目录，将被用于同期中mount的目录
  secret:       　　　 #类型为secret的存储卷，挂载集群与定义的secret对象到容器内部


pod控制器：管理pod，使pod达到期望的目标状态
pod控制器常见类型：
◇ ReplicaSet：保证副本数量一直维持在期望值，并支持pod数量扩缩容，镜像版本升级
◇ Deployment：通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本
◇ HPA：可以根据集群负载自动水平调整Pod的数量，实现削峰填谷
◇ DaemonSet：在集群中的指定Node上运行且仅运行一个副本，一般适用于日志收集、节点监控等场景
◇ Job：它创建出来的pod只要完成任务就立即退出，不需要重启或重建，用于执行一次性任务
◇ Cronjob：它创建的Pod负责周期性任务控制，不需要持续后台运行

Deployment：


版本回退
deployment支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能，下面具体来看.
kubectl rollout： 版本升级相关功能，支持下面的选项：
◇ status 显示当前升级状态
◇ history 显示 升级历史记录
◇ pause 暂停版本升级过程
◇ resume 继续已经暂停的版本升级过程
◇ restart 重启版本升级过程
◇ undo 回滚到上一级版本（可以使用--to-revision回滚到指定版本）

金丝雀发布
Deployment控制器支持控制更新过程中的控制，如“暂停(pause)”或“继续(resume)”更新操作。
比如有一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。
kubectl set image deploy pc-deployment nginx=nginx:1.17.4 -n dev && kubectl rollout pause deployment pc-deployment -n dev
kubectl rollout resume deploy pc-deployment -n dev

HPA可以获取每个Pod利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod的数量的调整。其实HPA与之前的Deployment一样，也属于一种Kubernetes资源对象，它通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理。
targetCPUUtilizationPercentage: 3 # CPU使用率指标

DaemonSet类型的控制器可以保证在集群中的每一台（或指定）节点上都运行一个副本。一般适用于日志收集、节点监控等场景。也就是说，如果一个Pod提供的功能是节点级别的（每个节点都需要且只需要一个），那么这类Pod就适合使用DaemonSet类型的控制器创建。



service：
在kubernetes中，pod是应用程序的载体，我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，这也就意味着不方便直接采用pod的ip对服务进行访问。
为了解决这个问题，kubernetes提供了Service资源，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务

type: # Service类型，指定service的访问方式
clusterIP:  # 虚拟服务的ip地址
sessionAffinity: # session亲和性，支持ClientIP、None两个选项
• ClusterIP：默认值，它是Kubernetes系统自动分配的虚拟IP，只能在集群内部访问
• NodePort：将Service通过指定的Node上的端口暴露给外部，通过此方法，就可以在集群外部访问服务
• LoadBalancer：使用外接负载均衡器完成到服务的负载分发，注意此模式需要外部云环境支持
• ExternalName： 把集群外部的服务引入集群内部，直接使用


Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后它会将最新的Service信息转换成对应的访问规则。

kube-proxy目前支持三种工作模式:
userspace 模式
userspace模式下，kube-proxy会为每一个Service创建一个监听端口，发向Cluster IP的请求被Iptables规则重定向到kube-proxy监听的端口上，kube-proxy根据LB算法选择一个提供服务的Pod并和其建立链接，以将请求转发到Pod上。 ​ 该模式下，kube-proxy充当了一个四层负责均衡器的角色。由于kube-proxy运行在userspace中，在进行转发处理时会增加内核和用户空间之间的数据拷贝，虽然比较稳定，但是效率比较低。

iptables 模式
iptables模式下，kube-proxy为service后端的每个Pod创建对应的iptables规则，直接将发向Cluster IP的请求重定向到一个Pod IP。 ​ 该模式下kube-proxy不承担四层负责均衡器的角色，只负责创建iptables规则。该模式的优点是较userspace模式效率更高，但不能提供灵活的LB策略，当后端Pod不可用时也无法进行重试。

ipvs 模式
ipvs模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法。一般推荐ipvs模式

数据存储
数据存储方式：

安全认证
kubernetes集群监控