一. k8s基本概念

目录

• k8s master/node节点组件
  • master
  • Lable
    • Label
    • Label Selector
  • Pod
    • 自主式pod
    • 控制管理器管理的pod
  • 小贴士
  • 后续需要继续了解的问题

k8s master/node节点组件

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