k8s master/node节点组件

一. k8s基本概念_回滚

master

  • API server

    • 提供集群管理的 RESTFUL API 接口，包括认证授权、数据校验以及集群状态变更等
    • 提供其他模块之间的数据交互和通信的枢纽（其他模块通过 API Server 查询或修改数据，只有 API Server 才直接操作 etcd）

  • Scheduler

    • kube-scheduler 负责分配调度 Pod 到集群内的节点上，它监听 kube-apiserver，查询还未分配 Node 的 Pod，然后根据调度策略为这些 Pod 分配节点（更新 Pod 的 NodeName 字段）。

  • Controller-Manager

    • Controller Manager 由 kube-controller-manager 和 cloud-controller-manager 组成，是 Kubernetes 的大脑，它通过 apiserver 监控整个集群的状态，并确保集群处于预期的工作状态。

Lable

Label

Label是Kubernetes系统中的一个核心概念。Label以key/value键值对的形式附加到任何对象上，如Pod，Service，Node，RC（ReplicationController）/RS（ReplicaSet）等。Label可以在创建对象时就附加到对象上，也可以在对象创建后通过API进行额外添加或修改。

apiVersion: v1
kind: Pod
metadata:            #通常使用metadata.labels字段，来为对象添加Label。Label可以为多个。
name: nginx
labels:            #名为nginx的Pod添加了两个Label，分别为app: nginx和release: stable。
 app: nginx       #app:nginx
 release: stable  #release:stable
spec:
 containers:
  - name: nginx
 image: nginx
 ports:
    - containerPort: 80

Label Selector

  • 通常我们通过描述文件中的spec.selector字段来指定Label，从而Kubernetes寻找到所有包含你指定Label的对象，进行管理。
  • Kubernetes目前支持两种类型的Label Selector：

    • 基于等式的Selector（Equality-based）

      • app=nginx 选择所有Label中key为app，value为nginx的对象。
      • env!=dev 选择所有Label中key为env，value不等于dev的对象。

    • 基于集合的Selector（Set-based）

      • name in (redis-master, redis-slave) 选择所有Label中key为name，并且value为redis-master或redis-slave的对象。
      • env not in (dev) 选择所有Label中key为env，并且value不为dev的对象。

    • Label是自定义的一些key/value对，你可以随心所欲的设置。

使用Label可以给对象创建一组或多组标签，Service，RC/RS等组件则通过Label Selector来定位需要管理的对象，Label和Label Selector共同构成了Kubernetes系统中最核心的应用模型，使得对象能够精细分组，同时实现了集群的高可用性。

Pod

自主式pod

  1. 直接kubectl run启动
  2. 自主式pod在非正常结束的情况下无法自动重新启动一个新的Pod

控制管理器管理的pod

  • ReplicationController

    RC保证了在所有时间内，都有特定数量的Pod副本正在运行，如果太多了，RC就杀死几个，如果太少了，RC会新建几个

  • ReplicaSet

    ReplicaSet是下一代复本控制器。ReplicaSet和 Replication Controller之间的唯一区别是现在的选择器支持。Replication Controller只支持基于等式的selector（env=dev或environment!=qa），但ReplicaSet还支持新的，基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)）。在试用时官方推荐ReplicaSet。

    大多数kubectl支持Replication Controller的命令也支持ReplicaSets。rolling-update命令有一个例外 。如果您想要滚动更新功能，请考虑使用Deployments。此外， rolling-update命令是必须的，而Deployments是声明式的，因此我们建议通过rollout命令使用Deployments。

    虽然ReplicaSets可以独立使用，但是今天它主要被 Deployments 作为协调pod创建，删除和更新的机制。当您使用Deployments时，您不必担心管理他们创建的ReplicaSets。Deployments拥有并管理其ReplicaSets。

  • Deployment

    特点:

    • 定义Deployment来创建Pod和ReplicaSet
    • 滚动升级和回滚应用
    • 扩容和缩容
    • 暂停和继续Deployment

    扩容：

    kubectl scale deployment nginx-deployment --replicas 10

    如果集群支持 horizontal pod autoscaling 的话，还可以为Deployment设置自动扩展：

    kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

    更新镜像也比较简单:

    kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

    回滚：

    kubectl rollout undo deployment/nginx-deployment

    Deployment为Pod和Replica Set提供声明式更新。

    你只需要在Deployment中描述你想要的目标状态是什么，Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment，也可以创建一个新的替换旧的Deployment。

    一个典型的用例如下：

    • 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态，看它是成功还是失败。
    • 然后，通过更新 Deployment 的 Pod.Template.Spec 字段来声明Pod的新状态。这会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
    • 如果当前状态不稳定，回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。
    • 扩容Deployment以满足更高的负载。
    • 暂停Deployment来应用 Pod.Template.Spec 的多个修复，然后恢复上线。
    • 根据Deployment 的状态判断上线是否hang住了。
    • 清除旧的不必要的ReplicaSet。

  • StatefulSet

    管理有状态应用

  • DaemonSet

    用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务

  • Job

    只要完成就立即退出，不需要重启或重建。

  • Cronjob

    周期性任务控制，不需要持续后台运行

小贴士

service识别后端pod主要通过lable
每创建一个service都相当于创建一个ipvs nat模型的规则

后续需要继续了解的问题

日志收集、监控和集群的备份

参考链接: https://www.kubernetes.org.cn/docs