kubernetes

K8s简介

他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

Kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

通过Kubernetes你可以：

• 快速部署应用
• 快速扩展应用
• 无缝对接新的应用功能
• 节省资源，优化硬件资源的使用

Kubernetes 特点

• 可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）
• 可扩展: 模块化, 插件化, 可挂载, 可组合
• 自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

K8s总体架构

K8s集群由两节点组成：

Master和Node。在Master上运行etcd,Api Server,Controller Manager和Scheduler四个组件。后三个组件构成了K8s的总控中心，负责对集群中所有资源进行管控和调度.在每个node上运行kubectl,proxy和docker daemon三个组件,负责对节点上的Pod的生命周期进行管理，以及实现服务代理的功能。另外所有节点上都可以运行kubectl命令行工具。

API Server作为集群的核心，负责集群各功能模块之间的通信。集群内的功能模块通过Api Server将信息存入到etcd,其他模块通过Api Server读取这些信息，从而实现模块之间的信息交互。Node节点上的Kubelet每隔一个时间周期，通过Api Server报告自身状态，Api Server接收到这些信息后，将节点信息保存到etcd中。Controller Manager中 的node controller通过Api server定期读取这些节点状态信息，并做响应处理。Scheduler监听到某个Pod创建的信息后，检索所有符合该pod要求的节点列表，并将pod绑定到节点列表中最符合要求的节点上。如果scheduler监听到某个Pod被删除，则调用api server删除该Pod资源对象。kubelet监听pod信息，如果监听到pod对象被删除，则删除本节点上的相应的pod实例，如果监听到修改Pod信息，则会相应地修改本节点的Pod实例。

[外链图片转存中…(img-nQ21vvPQ-1639737586493)]

Kubernetes主要由以下几个核心组件组成：

• etcd保存了整个集群的状态；
• apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
• controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
• kubelet负责本Node节点上的Pod的创建、修改、监控、删除等生命周期管理，同时Kubelet定时“上报”本Node的状态信息到Api Server里；
• Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
• kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

Kubernetes可以做什么？

使用Web服务，用户希望应用程序能够7*24小时全天运行，开发人员希望每天多次部署新的应用版本。通过应用容器化可以实现这些目标，使应用简单、快捷的方式更新和发布，也能实现热更新、迁移等操作。使用Kubernetes能确保程序在任何时间、任何地方运行，还能扩展更多有需求的工具/资源。Kubernetes积累了Google在容器化应用业务方面的经验，以及社区成员的实践，是能在生产环境使用的开源平台。

kubernetes术语

官方把 kubernetes 术语分为 12 个分类：
系统结构、社区、核心对象、扩展、基础、网络、操作、安全、存储、工具、用户类型、工作负载

由于 k8s 的术语实在太多了，想要全部记住作为新学者还是有点压力，所以我们课程中只讲解一些常用的术语。想要了解更多 kubernetes 术语，请参照官方术语表。
地址：https://kubernetes.io/docs/reference/glossary/?fundamental=true

Pod

Pod是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。

一个Pod封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod代表部署的一个单位：Kubernetes中单个应用的实例，它可能由单个容器或多个容器共享组成的资源。

Pods提供两种共享资源：网络和存储。

网络

每个Pod被分配一个独立的IP地址，Pod中的每个容器共享网络命名空间，包括IP地址和网络端口。Pod内的容器可以使用localhost相互通信。当Pod中的容器与Pod 外部通信时，他们必须协调如何使用共享网络资源（如端口）。

存储

Pod可以指定一组共享存储volumes。Pod中的所有容器都可以访问共享volumes，允许这些容器共享数据。volumes 还用于Pod中的数据持久化，以防其中一个容器需要重新启动而丢失数据。

[外链图片转存中…(img-SPKyItNX-1639737586494)]

Labelsabels其实就一对 key/value ，其中key与value由用户自己指定。Label可以附加到各种资源对象上。例如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label。

我们可以给指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能，以便于灵活、方便地进行资源分配、调度、配置、部署等管理工作。一些常用的Label示例：

"labels": {
 	"key1" : "value1",
 	"key2" : "value2"
 }

Namespace
Namespace 是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的pods, services, replication controllers和deployments等都是属于某一个namespace的（默认是default），而node, persistentVolumes等则不属于任何namespace。

Namespace常用来隔离不同的用户，比如Kubernetes自带的服务一般运行在kube-system namespace中。

Replication Controller

RC是K8s系统中的核心概念之一，简单来说，它其实定义了一个期望的场景。即声明某种Pod的副本数量在任意时刻都符合某个预期值。RC包括以下几个部分：

• Pod期待的副本数
• 用于筛选目标Pod的Label Selector。
• 当Pod的副本数量小于预期数量时，用于创建新的Pod模板（template）

当我们定义了一个RC并提交到了K8s集群以后，Master几点上的Controller Manager组件就得到通知，定时巡检系统中目前存活的目标Pod,并且确保目标Pod实例的数量刚好等于此RC的期望值。如果有过多的副本在运行，系统就会停掉一些Pod,否则系统就会再自动创建一些Pod。

NodeNode节点是K8s集群中的工作负载节点，当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上。

Node节点运行着以下一组关键过程：

• kubelet: 负责Pod对应容器的创建、启停等任务。
• kube-proxy: 实现k8s service的通信和负载均衡机制的重要组件。

[外链图片转存中…(img-ePyxuK6d-1639737586495)]](http://itoak.gitee.io/blog-articles/docker/imges/5.png)

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

ServicesKubernetes Pod 是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。如果有一组Pod组成一个集群来提供服务，那么如何来访问他们呢？

一个Service可以看成一组提供相同服务的Pod的对外访问接口。

Pod的Ip地址和Service的Cluster IP地址：

Pod的Ip地址是Docker Daemon根据docker0网桥的Ip地址段进行分配的，但Service的Cluster IP地址是k8s系统中的虚拟IP地址。Service的Cluster IP地址相对于Pod的IP地址来说相对稳定。

外部访问Service

由于Service对象在Cluster IP Range池中分配的IP地址只能在内部访问，所以其他Pod都可以无障碍地访问它。

K8s提供两种对外提供服务的Service的Type定义：Nodeport和LoadBalance

Volumes
容器中的磁盘的生命周期是短暂的，这就带来了一系列的问题，第一，当一个容器损坏之后，kubelet 会重启这个容器，但是文件会丢失-这个容器会是一个全新的状态，第二，当很多容器在同一Pod中运行的时候，很多时候需要数据文件的共享。Kubernete Volume解决了这个问题。

PV/PVC/StorageClass
PersistentVolume（PV）是集群中已由管理员配置的一段网络存储。 集群中的资源就像一个节点是一个集群资源。 PV是诸如卷之类的卷插件，但是具有独立于使用PV的任何单个pod的生命周期。 该API对象捕获存储的实现细节，即NFS，iSCSI或云提供商特定的存储系统。

PersistentVolumeClaim（PVC）是用户存储的请求。 它类似于pod。 Pod消耗节点资源，PVC消耗光伏资源。 荚可以请求特定级别的资源（CPU和内存）。 权利要求可以请求特定的大小和访问模式（例如，可以一旦读/写或只读许多次安装）。
虽然PersistentVolumeClaims允许用户使用抽象存储资源，但是常见的是，用户需要具有不同属性（如性能）的PersistentVolumes，用于不同的问题。 群集管理员需要能够提供多种不同于PersistentVolumes的PersistentVolumes，而不仅仅是大小和访问模式，而不会使用户了解这些卷的实现细节。 对于这些需求，存在StorageClass资源。

StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。 不同的类可能映射到服务质量级别，或备份策略，或者由群集管理员确定的任意策略。 Kubernetes本身对于什么类别代表是不言而喻的。 这个概念有时在其他存储系统中称为“配置文件”

例子
https://kubernetes.io/docs/user-guide/persistent-volumes/walkthrough/

DeploymentDeployment是V1.2引入的新概念，引入的目的是为了更好地解决Pod的编排问题。为此Deployment在内部使用了Replica Set来实现目的。Deployment相对于RC的一个最大升级是我们可以随时知道当前Pod部署的进度。

Deployment的使用场景：

• 创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建过程。
• 检查Deployment的状态来看部署动作是否完成。
• 更新Deployment以创建新的Pod(比如镜像升级)
• 如果当前的Deployment不稳定，则回滚到早先的Deployment版本
• 拓展Deployment以应对高负载。
• 清理不在需要的旧版本ReplicaSets。

比如一个简单的nginx应用可以定义为：

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

扩容：

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

Secret
Secret解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用。
Secret有三种类型：

• Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中；
• Opaque：base64编码格式的Secret，用来存储密码、密钥等；
• kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。

StatefulSet
StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用场景包括：

• 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
• 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
• 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
• 有序收缩，有序删除（即从N-1到0）

从上面的应用场景可以发现，StatefulSet由以下几个部分组成：

• 用于定义网络标志（DNS domain）的Headless Service
• 用于创建PersistentVolumes的volumeClaimTemplates
• 定义具体应用的StatefulSet

DaemonSet
DaemonSet保证在每个Node上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：

• 日志收集，比如fluentd，logstash等
• 系统监控，比如Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等
• 系统程序，比如kube-proxy, kube-dns, glusterd, ceph等

Service Account
Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的。

CronJob
CronJob即定时任务，就类似于Linux系统的crontab，在指定的时间周期运行指定的任务。在Kubernetes 1.5，使用CronJob需要开启batch/v2alpha1 API，即–runtime-config=batch/v2alpha1。

Job
Job负责批量处理短暂的一次性任务 (short lived one-off tasks)，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。

Kubernetes支持以下几种Job：

• 非并行Job：通常创建一个Pod直至其成功结束
• 固定结束次数的Job：设置.spec.completions，创建多个Pod，直到.spec.completions个Pod成功结束
• 带有工作队列的并行Job：设置.spec.Parallelism但不设置.spec.completions，当所有Pod结束并且至少一个成功时，Job就认为是成功

Security Context 和 PSP
Security Context的目的是限制不可信容器的行为，保护系统和其他容器不受其影响。
Kubernetes提供了三种配置Security Context的方法：

• Container-level Security Context：仅应用到指定的容器
• Pod-level Security Context：应用到Pod内所有容器以及Volume
• Pod Security Policies（PSP）：应用到集群内部所有Pod以及Volume

Pod Security Policies（PSP）是集群级的Pod安全策略，自动为集群内的Pod和Volume设置Security Context。
使用PSP需要API Server开启extensions/v1beta1/podsecuritypolicy，并且配置PodSecurityPolicyadmission控制器。

Resource Quotas
资源配额（Resource Quotas）是用来限制用户资源用量的一种机制。
它的工作原理为：

• 资源配额应用在Namespace上，并且每个Namespace最多只能有一个ResourceQuota对象
• 开启计算资源配额后，创建容器时必须配置计算资源请求或限制（也可以用LimitRange设置默认值）
• 用户超额后禁止创建新的资源

Network Policy
Network Policy提供了基于策略的网络控制，用于隔离应用并减少攻击面。它使用标签选择器模拟传统的分段网络，并通过策略控制它们之间的流量以及来自外部的流量。
在使用Network Policy之前，需要注意：

• apiserver开启extensions/v1beta1/networkpolicies
• 网络插件要支持Network Policy，如Calico、Romana、Weave Net和trireme等

Ingress
通常情况下，service和pod的IP仅可在集群内部访问。集群外部的请求需要通过负载均衡转发到service在Node上暴露的NodePort上，然后再由kube-proxy将其转发给相关的Pod。
而Ingress就是为进入集群的请求提供路由规则的集合，如下图所示

[外链图片转存中…(img-WcH6XrF7-1639737586495)]

Ingress可以给service提供集群外部访问的URL、负载均衡、SSL终止、HTTP路由等。为了配置这些Ingress规则，集群管理员需要部署一个Ingress controller，它监听Ingress和service的变化，并根据规则配置负载均衡并提供访问入口。

ThirdPartyResources
ThirdPartyResources是一种无需改变代码就可以扩展Kubernetes API的机制，可以用来管理自定义对象。

hirdPartyResources将在v1.7弃用

ThirdPartyResources将在v1.7弃用，并在未来版本中删除。建议从v1.7开始，迁移到CustomResourceDefinition。

ConfigMap
ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。ConfigMap跟secret很类似，但它可以更方便地处理不包含敏感信息的字符串。

PodPreset
s是一种无需改变代码就可以扩展Kubernetes API的机制，可以用来管理自定义对象。

hirdPartyResources将在v1.7弃用

ThirdPartyResources将在v1.7弃用，并在未来版本中删除。建议从v1.7开始，迁移到CustomResourceDefinition。