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