kubernetes

kubernetes是一个可以自动实施容器操作的开源平台。生产化的容器编排系统，可自动部署，扩展和管理容器化应用。

Docker

1. namespaces 名称空间 ：资源隔离，UTS、IPC、PID、NETWORK、MOUNT、USER。。。
2. control Group 控制组：资源管理

功能：资源限制、优先级分配、资源统计、任务控制

核心组件

Master

• etcd：

  1. 保存了整个集群的状态，网络配置，对象状态信息及调度等信息；
  2. 基于Raft协议的分布式一致性KV存储；

• apiserver：提供了k8s各类资源对象（pod,RC,Service等）的增删改查及watch等HTTP Rest接口，是整个系统的数据总线和数据中心。

  1. 提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)；
  2. 提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd）;
  3. 是资源配额控制的入口；
  4. 拥有完备的集群安全机制.

  list-watch机制：

  1. `list`非常好理解，就是调用资源的`list API`罗列资源，基于`HTTP`短链接`实现` ;
   2.  `watch`则是调用资源的`watch API`监听资源变更事件，基于`HTTP 长链接`实现` ,会带上watch=true，监听资源的相关事件，有事件来临会返回一个WatchEvent

• controller manager：

  负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；

• scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；

• Dashboard：提供GUI

Node

• kubelet：
  1. 负责维护容器的生命周期，同时也负责Volume（CSI）和网络（CNI）的管理
  2. 处理master下发到本节点的任务，管理pod和pod中的容器
  3. 定期向master汇报状态
  4. 通过 cadvisor 组件监控节点和容器的使用情况
• Container runtime：
  1. 负责镜像管理以及Pod和容器的真正运行（CRI：容器和镜像的服务的接口）；
• kube-proxy：负责为Service提供cluster内部的服务发现和负载均衡；
• Ingress Controller：为服务提供外网入口
• Prometheus：提供资源监控

架构

1. 用户通过kubectl或者对外的restapi来进行操作，如部署新的应用
2. API Server接受到请求，将请求存储到etcd中
3. Watcher和Controller检测资源状态的变化，做出相应的操作
4. Controller根据请求进行控制，将创建出符合预期的pod
5. Scheduler将新的Pod分配到Kubelet
6. Kebelet检测到Pods,通过Container runtime部署
7. KubePorxy管理pod的网关，其中包含服务发现，负载均衡等

核心概念

Pod

1.一组紧密关联的容器集合

2. 共享PID, IPC, Network, namespace
3. k8s调度的基本单位
4. 将会调度到Node中

Node

Node 是 Kubernetes 集群的工作节点，可以是物理机也可以是虚拟机。

节点管理：

1. 禁止调度：`kubectl cordon <node>`
 2. 驱逐节点中的Pod：`kubectl drain <node>`

Namespace

提供独立的命名空间，因此可以实现部分的环境隔离

Labels

1. 可以标记任何对象
2. K-V形式

label selectors

1. equality-based ：可以使用=、==、!=操作符，可以使用逗号分隔多个表达式
2. set-based ：可以使用in、notin、!操作符，另外还可以没有操作符，直接写出某个label的key，表示过滤有某个 key的object而不管该key的value是何值，!表示没有该label的object

Controller

使用pod模板中的实际需要创建pod,并保证某种期望运行，提供副本管理，滚动升级，集群级别的自愈

ReplicationController

​ 确保指定的pod数运行，仅支持equality-based selector

ReplicationSet

​ RC的升级版，可以支持set-based selector

Deployment

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

1. 声明式的方式通过 ReplicationSet来管理Pods
2. 可以实现灰度发布升级等
3. 扩缩容

StatuefulSet

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: gcr.io/google_containers/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
      annotations:
        volume.beta.kubernetes.io/storage-class: anything
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

1. 保证部署和 scale 的顺序
2. 解决有状态服务的问题

DaemonSet

1. 确保全部（或者一些）Node 上运行一个 Pod 的副本

Job CronJob。。。

Node Controller

节点控制器

操作：节点隔离，节点驱逐，节点恢复等

CRD （ CustomResourceDefinition ）

参考链接：https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/

Kubernetes 1.7 之后增加了对 CRD 自定义资源二次开发能力来扩展 Kubernetes API，通过 CRD 我们可以向 Kubernetes API 中增加新资源类型，而不需要修改 Kubernetes 源码来创建自定义的 API server，该功能大大提高了 Kubernetes 的扩展能力。当你创建一个新的CustomResourceDefinition (CRD)时，Kubernetes API服务器将为你指定的每个版本创建一个新的RESTful资源路径，我们可以根据该api路径来创建一些我们自己定义的类型资源。CRD可以是命名空间的，也可以是集群范围的，由CRD的作用域(scpoe)字段中所指定的，与现有的内置对象一样，删除名称空间将删除该名称空间中的所有自定义对象。customresourcedefinition本身没有名称空间，所有名称空间都可以使用。

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  # name must match the spec fields below, and be in the form: <plural>.<group>
  name: crontabs.stable.example.com
spec:
  # group name to use for REST API: /apis/<group>/<version>
  group: stable.example.com
  # list of versions supported by this CustomResourceDefinition
  versions:
    - name: v1
      # Each version can be enabled/disabled by Served flag.
      served: true
      # One and only one version must be marked as the storage version.
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                image:
                  type: string
                replicas:
                  type: integer
  # either Namespaced or Cluster
  scope: Namespaced
  names:
    # plural name to be used in the URL: /apis/<group>/<version>/<plural>
    plural: crontabs
    # singular name to be used as an alias on the CLI and for display
    singular: crontab
    # kind is normally the CamelCased singular type. Your resource manifests use this.
    kind: CronTab
    # shortNames allow shorter string to match your resource on the CLI
    shortNames:
    - ct