Kubernetes官网//可支持中文
Kubernetes 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。
Kubernetes 这个名字源于希腊语,意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。 Google 在 2014 年开源了 Kubernetes 项目。Kubernetes 建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验 的基础上,结合了社区中最好的想法和实践。
时光回溯
让我们回顾一下为什么 Kubernetes 如此有用。
传统部署时代:
早期,各个组织机构在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界,这会导致资源分配问题。 例如,如果在物理服务器上运行多个应用程序,则可能会出现一个应用程序占用大部分资源的情况, 结果可能导致其他应用程序的性能下降。 一种解决方案是在不同的物理服务器上运行每个应用程序,但是由于资源利用不足而无法扩展, 并且维护许多物理服务器的成本很高。
虚拟化部署时代:
作为解决方案,引入了虚拟化。虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机(VM)。 虚拟化允许应用程序在 VM 之间隔离,并提供一定程度的安全,因为一个应用程序的信息 不能被另一应用程序随意访问。
虚拟化技术能够更好地利用物理服务器上的资源,并且因为可轻松地添加或更新应用程序 而可以实现更好的可伸缩性,降低硬件成本等等。
每个 VM 是一台完整的计算机,在虚拟化硬件之上运行所有组件,包括其自己的操作系统。
容器部署时代:
容器类似于 VM,但是它们具有被放宽的隔离属性,可以在应用程序之间共享操作系统(OS)。 因此,容器被认为是轻量级的。容器与 VM 类似,具有自己的文件系统、CPU、内存、进程空间等。 由于它们与基础架构分离,因此可以跨云和 OS 发行版本进行移植。
容器因具有许多优势而变得流行起来。下面列出的是容器的一些好处:
容器是打包和运行应用程序的好方式。在生产环境中,你需要管理运行应用程序的容器,并确保不会停机。 例如,如果一个容器发生故障,则需要启动另一个容器。如果系统处理此行为,会不会更容易?
这就是 Kubernetes 来解决这些问题的方法! Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。 例如,Kubernetes 可以轻松管理系统的 Canary 部署。
Kubernetes 为你提供:
服务发现和负载均衡
Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器,如果进入容器的流量很大, Kubernetes 可以负载均衡并分配网络流量,从而使部署稳定。
存储编排
Kubernetes 允许你自动挂载你选择的存储系统,例如本地存储、公共云提供商等。
自动部署和回滚
你可以使用 Kubernetes 描述已部署容器的所需状态,它可以以受控的速率将实际状态 更改为期望状态。例如,你可以自动化 Kubernetes 来为你的部署创建新容器, 删除现有容器并将它们的所有资源用于新容器。
自动完成装箱计算
Kubernetes 允许你指定每个容器所需 CPU 和内存(RAM)。 当容器指定了资源请求时,Kubernetes 可以做出更好的决策来管理容器的资源。
自我修复
Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的 运行状况检查的容器,并且在准备好服务之前不将其通告给客户端。
密钥与配置管理
Kubernetes 允许你存储和管理敏感信息,例如密码、OAuth 令牌和 ssh 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置,也无需在堆栈配置中暴露密钥。
Kubernetes 不是什么
Kubernetes 不是传统的、包罗万象的 PaaS(平台即服务)系统。 由于 Kubernetes 在容器级别而不是在硬件级别运行,它提供了 PaaS 产品共有的一些普遍适用的功能, 例如部署、扩展、负载均衡、日志记录和监视。 但是,Kubernetes 不是单体系统,默认解决方案都是可选和可插拔的。 Kubernetes 提供了构建开发人员平台的基础,但是在重要的地方保留了用户的选择和灵活性。
Kubernetes:
不限制支持的应用程序类型。 Kubernetes 旨在支持极其多种多样的工作负载,包括无状态、有状态和数据处理工作负载。 如果应用程序可以在容器中运行,那么它应该可以在 Kubernetes 上很好地运行。
不部署源代码,也不构建你的应用程序。 持续集成(CI)、交付和部署(CI/CD)工作流取决于组织的文化和偏好以及技术要求。
不提供应用程序级别的服务作为内置服务,例如中间件(例如,消息中间件)、 数据处理框架(例如,Spark)、数据库(例如,mysql)、缓存、集群存储系统 (例如,Ceph)。这样的组件可以在 Kubernetes 上运行,并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制(例如, 开放服务代理)来访问。
不要求日志记录、监视或警报解决方案。 它提供了一些集成作为概念证明,并提供了收集和导出指标的机制。
不提供或不要求配置语言/系统(例如 jsonnet),它提供了声明性 API, 该声明性 API 可以由任意形式的声明性规范所构成。
不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。
此外,Kubernetes 不仅仅是一个编排系统,实际上它消除了编排的需要。 编排的技术定义是执行已定义的工作流程:首先执行 A,然后执行 B,再执行 C。 相比之下,Kubernetes 包含一组独立的、可组合的控制过程, 这些过程连续地将当前状态驱动到所提供的所需状态。 如何从 A 到 C 的方式无关紧要,也不需要集中控制,这使得系统更易于使用 且功能更强大、系统更健壮、更为弹性和可扩展。
Kubernetes 架构是一个比较典型的二层架构和 Server-Client 架构。Master 作为中央的管控节点,会去与 Node 进行一个连接。客户端(比如UI/CLI等)只会和 Master 进行连接,把希望的状态或者想执行的命令下发给 Master,Master 会把这些命令或者状态下发给相应的节点,进行最终的执行。
Kubernetes 的 Master 包含四个主要的组件:kube-apiserver、kube-controller、kube-scheduler 以及 etcd,如下图所示。我们一般也称Master节点为控制面(Control Plane),控制面的这4个组件对集群做出全局决策(比如把Pod调度到某个合适的节点上),以及检测和响应集群事件。
各组件的作用简要概括如下:
Kubernetes 的 Node 是真正运行业务负载的,每个业务负载会以 Pod 的形式运行。一个 Pod 中运行一个或者多个容器,真正去运行这些 Pod 的组件的是叫做 kubelet,也就是 Node 上最为关键的组件,它通过 API Server 接收到所需要 Pod 运行的状态,然后提交到我们下面画的这个 Container Runtime 组件(简单的理解也就是平时我们所说的容器)中。
各组件的作用概括如下:
另外,上图中还有 Storage Plugin 和 Network Plugin,这些是 Kubernetes 的插件(addons),而不是 Kubernetes 本身就实现的,这些插件使用 Kubernetes 资源 (DaemonSet, Deployment等) 的形式实现集群功能。因为插件提供的功能是集群级别的,所以插件的命名空间资源属于 kube-system
命名空间,看起来就像 Kubeenetes 本身提供的原生功能一样。比如网络插件比较出名的就有 Calico 和 Flannel。
需要强调的是,Kubernetes 的 Node 并不会直接和用户进行交互,它的交互只会通过 Master,用户通过 Master 向节点下发信息。Kubernetes 每个 Node 上,都会运行刚才提到的这几个组件。
总结:
为了深入理解各个组件的交互过程,对**「拉起一个Pod的具体过程」**需要有非常细致的了解。
Master是集群的控制节点,每个K8s集群里需要有一个Master节点来负责整个集群的管理和控制。基本上k8s的所有控制命令都发给它,它来负责整个具体的执行过程。Master节点通常占据一个独立的服务器(高可用部署建议3台服务器)。
Master节点运行着以下一组关键过程:
Node节点是K8s集群中的工作负载节点,当某个Node宕机时,其上的工作负载会被Master自动转移到其他节点上。
Node节点运行着以下一组关键过程:
Pod是Kubernetes创建或部署的最小/最简单的基本单位,一个Pod代表集群上正在运行的一个进程。
一个Pod封装一个应用容器(也可以有多个容器),存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod代表部署的一个单位:Kubernetes中单个应用的实例,它可能由单个容器或多个容器共享组成的资源。
Pods提供两种共享资源:网络和存储。
网络
每个Pod被分配一个独立的IP地址,Pod中的每个容器共享网络命名空间,包括IP地址和网络端口。Pod内的容器可以使用localhost相互通信。当Pod中的容器与Pod 外部通信时,他们必须协调如何使用共享网络资源(如端口)。
存储
Pod可以指定一组共享存储volumes。Pod中的所有容器都可以访问共享volumes,允许这些容器共享数据。volumes 还用于Pod中的数据持久化,以防其中一个容器需要重新启动而丢失数据。
Pod容器结构如下图所示:
Pod生命周期:
Pod 的 status 定义在 PodStatus 对象中,其中有一个 phase 字段。
下面是 phase 可能的值:
Labels其实就一对 key/value ,其中key与value由用户自己指定。Label可以附加到各种资源对象上。例如Node、Pod、Service、RC等,一个资源对象可以定义任意数量的Label。
我们可以给指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能,以便于灵活、方便地进行资源分配、调度、配置、部署等管理工作。一些常用的Label示例:
RC是K8s系统中的核心概念之一,简单来说,它其实定义了一个期望的场景。即声明某种Pod的副本数量在任意时刻都符合某个预期值。RC包括以下几个部分:
当我们定义了一个RC并提交到了K8s集群以后,Master几点上的Controller Manager组件就得到通知,定时巡检系统中目前存活的目标Pod,并且确保目标Pod实例的数量刚好等于此RC的期望值。如果有过多的副本在运行,系统就会停掉一些Pod,否则系统就会再自动创建一些Pod。
Deployment是V1.2引入的新概念,引入的目的是为了更好地解决Pod的编排问题。为此Deployment在内部使用了Replica Set来实现目的。Deployment相对于RC的一个最大升级是我们可以随时知道当前Pod部署的进度。
Deployment的使用场景:
Kubernetes 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
1)Nodeport
apiVersion: v1
kind:``Service
metadata:
labels:
name: hello
name: hello
spec:
type:``NodePort
ports:
- port:``8080
nodePort:``30008
selector:
name: hello
假设有3个hello Pod运行在3个不同的Node上,客户端访问其中任意一个Node都可以访问到这个服务。
2)LoadBalance
kind:``Service
apiVersion: v1
metadata:
name:``my-service
spec:
selector:
app:``MyApp
ports:
- protocol: TCP
port:``80
targetPort:``9376
nodePort:``30061
clusterIP:``10.0.171.239
loadBalancerIP:``78.11.24.19
type:``LoadBalancer
status:
loadBalancer:
ingress:
- ip:``146.148.47.155
status.loadBalancer.ingress.ip设置的146.148.47.155为云提供商提供的负载均衡器的IP地址,
默认情况下容器中的磁盘文件是非持久化的,对于运行在容器中的应用来说面临两个问题,第一:当容器挂掉kubelet将重启启动它时,文件将会丢失;第二:当Pod中同时运行多个容器,容器之间需要共享文件时。Kubernetes的Volume解决了这两个问题。
在Docker中也有一个docker Volume的概念 ,Docker的Volume只是磁盘中的一个目录,生命周期不受管理。Kubernetes Volume具有明确的生命周期 - 与pod相同。在容器重新启动时能可以保留数据,当然,当Pod被删除不存在时,Volume也将消失。注意,Kubernetes支持许多类型的Volume,一个Pod可以同时使用任意类型/数量的Volume。
Kubernetes支持Volume类型有:
示例:
apiVersion: v1
kind:``Pod
metadata:
name: test-pd
spec:
containers:
- image: gcr.io/google_containers/test-webserver
name: test-container
volumeMounts:
- mountPath:``/cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir:``{}
apiVersion: v1
kind:``Pod
metadata:
name: test-pd
spec:
containers:
- image: gcr.io/google_containers/test-webserver
name: test-container
volumeMounts:
- mountPath:``/test-pd
name: test-volume
volumes:
- name: test-volume
hostPath:
# directory location on host
path:``/data
Namespace是K8s系统中非常重要的概念,通过将系统内部的对象“分配”到不同Namespace。K8s集群在启动后,会创建一个名为“default”的Namespace。
创建一个名为redis-master的Pod,放入到redis-namespace这个Namespace里。示例:
apiVersion: v1
kind:``Pod
metadata:
name: redis-master
namespace: redis-namespace
spec:
containers:
- name: master
image: kubeguide/redis-master
ports:
创建一个名为redis-master的Pod,放入到redis-namespace这个Namespace里。示例:
apiVersion: v1
kind:``Pod
metadata:
name: redis-master
namespace: redis-namespace
spec:
containers:
- name: master
image: kubeguide/redis-master
ports:
- containerPort:``6379