Kubernetes 简介

一、Kubernetes简介

1、概念

  Kubernetes（简称k8s）是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。
  在Kubernetes中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。

2、主要特性：

• 基于容器的应用部署、维护和滚动升级
• 负载均衡和服务发现
• 跨机器和跨地区的集群调度
• 自动伸缩
• 无状态服务和有状态服务
• 广泛的 Volume 支持
• 插件机制保证扩展性

二、Kubernetes 基本概念

1、Container

  Container（容器）是一种便携式、轻量级的操作系统级虚拟化技术。它使用 namespace 隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，从而使得容 器可以很方便的在任何地方运行。

2、Pod

  Kubernetes 使用 Pod 来管理容器，每个 Pod 可以包含一个或多个紧密关联的容器。 Pod 是一组紧密关联的容器集合，它们共享 PID、IPC、Network 和 UTS namespace， 是 Kubernetes 调度的基本单位。Pod 内的多个容器共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

3、Node

   Node 是 Pod 真正运行的主机，可以是物理机，也可以是虚拟机。为了管理 Pod，每个 Node 节点上至少要运行 container runtime（比如 docker 或者 rkt）、 kubelet 和 kube-proxy 服务。

4、Namespace

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

5、Service

   Service 是应用服务的抽象，通过 labels 为应用提供负载均衡和服务发现。匹配 labels 的 Pod IP 和端口列表组成 endpoints，由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。 每个 Service 都会自动分配一个 cluster IP（仅在集群内部可访问的虚拟地址）和 DNS 名，其他容器可以通过该地址或 DNS 来访问服务，而不需要了解后端容器的运行。

6、Label

   Label 是识别 Kubernetes 对象的标签，以 key/value 的方式附加到对象上（key 最长不 能超过 63 字节，value 可以为空，也可以是不超过 253 字节的字符串）。
   Label 不提供唯一性，并且实际上经常是很多对象（如 Pods）都使用相同的 label 来标 志具体的应用。 Label 定义好后其他对象可以使用 Label Selector 来选择一组相同 label 的对象（比如 ReplicaSet 和 Service 用 label 来选择一组 Pod）。
   Label Selector 支持以下几种方式：

• 等式，如 app=nginx 和 env!=production
• 集合，如 env in (production, qa)
• 多个 label（它们之间是 AND 关系），如 app=nginx,env=test

7、Annotations

   Annotations 是 key/value 形式附加于对象的注解。不同于 Labels 用于标志和选择对 象，Annotations 则是用来记录一些附加信息，用来辅助应用部署、安全策略以及调度 策略等。比如 deployment 使用 annotations 来记录 rolling update 的状态。

三、架构原理

1.核心组件

2.除了核心组件，还有一些推荐的 Add-ons：

• kube-dns 负责为整个集群提供 DNS 服务
• Ingress Controller 为服务提供外网入口
• Heapster 提供资源监控
• Dashboard 提供
• GUI Federation 提供跨可用区的集群 Fluentd-elasticsearch 提供集群日志采集、存储与查询

3.分层架构

Kubernetes 设计理念和功能其实就是一个类似 Linux 的分层架构，如下图所示

• 核心层：Kubernetes 最核心的功能，对外提供 API 构建高层的应用，对内提供插 件式应用执行环境
• 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服 务发现、DNS 解析等）
• 管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动 态 Provision 等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy 等）
• 接口层：kubectl 命令行工具、客户端 SDK 以及集群联邦
• 生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范 畴 Kubernetes 外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS 应用、ChatOps 等 Kubernetes 内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的 配置和管理等

4.架构图

5、资源对象

5.1、Persistent Volume

   Persistent Volume PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 提供了方便的持久化卷：PV 提供网络存储资源，而 PVC 请求存储资源。这样，设置持久化的工作流包括配置底层 文件系统或者云数据卷、创建持久性数据卷、最后创建 PVC 来将 Pod 跟数据卷关联起 来。PV 和 PVC 可以将 pod 和数据卷解耦，pod 不需要知道确切的文件系统或者支持它 的持久化引擎。
   Volume 生命周期 Volume 的生命周期包括 5 个阶段

• . Provisioning，即 PV 的创建，可以直接创建 PV（静态方式），也可以使用 StorageClass 动态创建
• Binding，将 PV 分配给 PVC
• Using，Pod 通过 PVC 使用该 Volume，并可以通过准入控制 StorageObjectInUseProtection（1.9 及以前版本为 PVCProtection）阻止删除正在 使用的 PVC
• Releasing，Pod 释放 Volume 并删除 PVC
• Reclaiming，回收 PV，可以保留 PV 以便下次使用，也可以直接从云存储中删除
• Deleting，删除 PV 并从云存储中删除后段存储
    根据这 5 个阶段，Volume 的状态有以下 4 种
• Available：可用
• Bound：已经分配给 PVC
• Released：PVC 解绑但还未执行回收策略
• Failed：发生错误

5.2、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

5.3、Deployment

   Deployment 为 Pod 和 Replica Set（下一代 Replication Controller）提供声明式更新。 你只需要在 Deployment 中描述你想要的目标状态是什么，Deployment controller 就会 帮你将 Pod 和 Replica Set 的实际状态改变到你的目标状态。你可以定义一个全新的 Deployment，也可以创建一个新的替换旧的 Deployment。
   一个典型的用例如下： 使用 Deployment 来创建 ReplicaSet。ReplicaSet 在后台创建 pod。检查启动状 态，看它是成功还是失败。 然后，通过更新 Deployment 的 PodTemplateSpec 字段来声明 Pod 的新状态。这会创建一个新的 ReplicaSet，Deployment 会按照控制的速率将 pod 从旧的 ReplicaSet 移动到新的 ReplicaSet 中。 如果当前状态不稳定，回滚到之前的 Deployment revision。每次回滚都会更新 Deployment 的 revision。 扩容 Deployment 以满足更高的负载。 暂停 Deployment 来应用 PodTemplateSpec 的多个修复，然后恢复上线。 根据 Deployment 的状态判断上线是否 hang 住了。 清除旧的不必要的 ReplicaSet。

5.4、ReplicationController 和 ReplicaSet

   ReplicationController（也简称为 rc）用来确保容器应用的副本数始终保持在用户定义的 副本数，即如果有容器异常退出，会自动创建新的 Pod 来替代；而异常多出来的容器也 会自动回收。ReplicationController 的典型应用场景包括确保健康 Pod 的数量、弹性伸 缩、滚动升级以及应用多版本发布跟踪等。
  在新版本的 Kubernetes 中建议使用 ReplicaSet（也简称为 rs）来取代 ReplicationController。ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字 不一样，并且 ReplicaSet 支持集合式的 selector（ReplicationController 仅支持等 式）。
  虽然也 ReplicaSet 可以独立使用，但建议使用 Deployment 来自动管理 ReplicaSet，这 样就无需担心跟其他机制的不兼容问题（比如 ReplicaSet 不支持 rolling-update 但 Deployment 支持），并且还支持版本记录、回滚、暂停升级等高级特性

5.5、Service

   Service是对一组提供相同功能的 Pods 的抽象，并为它们提供一个统一的入口。借助 Service，应用可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。 Service 通过标签来选取服务后端，一般配合 Replication Controller 或者 Deployment，Service 来保证后端容器的正常运行。这些匹配标签的 Pod IP 和端口列表组成 endpoints，由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。
Service 有四种类型：

• ClusterIP：默认类型，自动分配一个仅 cluster 内部可以访问的虚拟 IP
• NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可 以通过 :NodePort 来访问该服务。如果 kube-proxy 设置了 – nodeport-addresses=10.240.0.0/16 （v1.10 支持），那么仅该 NodePort 仅对 设置在范围内的 IP 有效。
• LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部的负载 均衡器，并将请求转发到 :NodePort
• ExternalName：将服务通过 DNS CNAME 记录方式转发到指定的域名（通过 spec.externlName 设定）。需要 kube-dns 版本在 1.7 以上。
     另外，也可以将已有的服务以 Service 的形式加入到 Kubernetes 集群中来，只需要在 创建 Service 的时候不指定 Label selector，而是在 Service 创建好后手动为其添加 endpoint。

5.6、DaemonSet DaemonSet

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

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

5.7、Secret

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

• Opaque：base64 编码格式的 Secret，用来存储密码、密钥等；但数据也通过 base64 --decode 解码得到原始数据，所有加密性很弱。
• kubernetes.io/dockerconfigjson ：用来存储私有 docker registry 的认证信 息。
• kubernetes.io/service-account-token ： 用于被 serviceaccount 引用。 serviceaccout 创建时 Kubernetes 会默认创建对应的 secret。Pod 如果使用了 serviceaccount，对应的 secret 会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中。
  备注：serviceaccount 用来使得 Pod 能够访问 Kubernetes API