Kubernetes

k8s(Kubernetes)介绍

本文主要是介绍k8s(Kubernetes)介绍,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

Kubernetes 简介

Kubernetes官网//可支持中文

Kubernetes 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。

Kubernetes 这个名字源于希腊语,意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。 Google 在 2014 年开源了 Kubernetes 项目。Kubernetes 建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验 的基础上,结合了社区中最好的想法和实践。

时光回溯

让我们回顾一下为什么 Kubernetes 如此有用。

在这里插入图片描述

传统部署时代:

早期,各个组织机构在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界,这会导致资源分配问题。 例如,如果在物理服务器上运行多个应用程序,则可能会出现一个应用程序占用大部分资源的情况, 结果可能导致其他应用程序的性能下降。 一种解决方案是在不同的物理服务器上运行每个应用程序,但是由于资源利用不足而无法扩展, 并且维护许多物理服务器的成本很高。

虚拟化部署时代:

作为解决方案,引入了虚拟化。虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机(VM)。 虚拟化允许应用程序在 VM 之间隔离,并提供一定程度的安全,因为一个应用程序的信息 不能被另一应用程序随意访问。

虚拟化技术能够更好地利用物理服务器上的资源,并且因为可轻松地添加或更新应用程序 而可以实现更好的可伸缩性,降低硬件成本等等。

每个 VM 是一台完整的计算机,在虚拟化硬件之上运行所有组件,包括其自己的操作系统。

容器部署时代:

容器类似于 VM,但是它们具有被放宽的隔离属性,可以在应用程序之间共享操作系统(OS)。 因此,容器被认为是轻量级的。容器与 VM 类似,具有自己的文件系统、CPU、内存、进程空间等。 由于它们与基础架构分离,因此可以跨云和 OS 发行版本进行移植。

容器因具有许多优势而变得流行起来。下面列出的是容器的一些好处:

  • 敏捷应用程序的创建和部署:与使用 VM 镜像相比,提高了容器镜像创建的简便性和效率。
  • 持续开发、集成和部署:通过快速简单的回滚(由于镜像不可变性),支持可靠且频繁的 容器镜像构建和部署。
  • 关注开发与运维的分离:在构建/发布时而不是在部署时创建应用程序容器镜像, 从而将应用程序与基础架构分离。
  • 可观察性:不仅可以显示操作系统级别的信息和指标,还可以显示应用程序的运行状况和其他指标信号。
  • 跨开发、测试和生产的环境一致性:在便携式计算机上与在云中相同地运行。
  • 跨云和操作系统发行版本的可移植性:可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方运行。
  • 以应用程序为中心的管理:提高抽象级别,从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
  • 松散耦合、分布式、弹性、解放的微服务:应用程序被分解成较小的独立部分, 并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
  • 资源隔离:可预测的应用程序性能。
  • 资源利用:高效率和高密度。

Kubernetes特性

容器是打包和运行应用程序的好方式。在生产环境中,你需要管理运行应用程序的容器,并确保不会停机。 例如,如果一个容器发生故障,则需要启动另一个容器。如果系统处理此行为,会不会更容易?

这就是 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 的方式无关紧要,也不需要集中控制,这使得系统更易于使用 且功能更强大、系统更健壮、更为弹性和可扩展。

Kubernets架构

Kubernetes 架构是一个比较典型的二层架构和 Server-Client 架构。Master 作为中央的管控节点,会去与 Node 进行一个连接。客户端(比如UI/CLI等)只会和 Master 进行连接,把希望的状态或者想执行的命令下发给 Master,Master 会把这些命令或者状态下发给相应的节点,进行最终的执行

Master

Kubernetes 的 Master 包含四个主要的组件:kube-apiserver、kube-controller、kube-scheduler 以及 etcd,如下图所示。我们一般也称Master节点为控制面(Control Plane),控制面的这4个组件对集群做出全局决策(比如把Pod调度到某个合适的节点上),以及检测和响应集群事件。

1564386046026-e89cd0ef-a9d3-4393-895e-f9e3de0ea6ef

各组件的作用简要概括如下:

  • kube-apiserver:顾名思义是用来处理 API 操作的,Kubernetes 中所有的组件都会和 API Server 进行连接,组件与组件之间一般不进行独立的连接,都依赖于 API Server 进行消息的传送;
  • **kube-controller-manager:**是控制器管理器,它用来完成对集群状态的管理。其中具体包括这几个控制器,如下所示:
    • Node controller: Responsible for noticing and responding when nodes go down.
    • Replication controller: Responsible for maintaining the correct number of pods for every replication controller object in the system.
    • Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods).
    • Service Account & Token controllers: Create default accounts and API access tokens for new namespaces
  • **kube-scheduler:**是调度器,“调度器”顾名思义就是完成调度的操作,该组件监视那些新创建的 Pod,并选择符合调节的节点让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰等。
  • **etcd:**是一个分布式的一个存储系统,API Server 中所需要的这些原信息都被放置在 etcd 中,etcd 本身是一个高可用系统,通过 etcd 保证整个 Kubernetes 的 Master 组件的高可用性。

Node

Kubernetes 的 Node 是真正运行业务负载的,每个业务负载会以 Pod 的形式运行。一个 Pod 中运行一个或者多个容器,真正去运行这些 Pod 的组件的是叫做 kubelet,也就是 Node 上最为关键的组件,它通过 API Server 接收到所需要 Pod 运行的状态,然后提交到我们下面画的这个 Container Runtime 组件(简单的理解也就是平时我们所说的容器)中。

1564386045894-314cdcb7-a039-4b0e-81b8-174215dd322a

各组件的作用概括如下:

  • kubelet:这是运行在每个工作节点上最重要的组件,kubelet 接收一组通过各类机制提供给它的 PodSpecs(也就是Pod的期望状态),确保这些 PodSpecs 中描述的容器处于运行状态且健康。
  • kube-proxy:kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络与 Pod 进行网络通信。它是实现Kubernetes Service概念的重要组件。
  • Container Runtime:容器运行时,指的是负责运行容器的软件,Kubernetes 支持多种容器运行时: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI 的容器。(初学者暂时可以把container runtime等同于Docker,或者平时所说的“容器”即可)

另外,上图中还有 Storage Plugin 和 Network Plugin,这些是 Kubernetes 的插件(addons),而不是 Kubernetes 本身就实现的,这些插件使用 Kubernetes 资源 (DaemonSet, Deployment等) 的形式实现集群功能。因为插件提供的功能是集群级别的,所以插件的命名空间资源属于 kube-system 命名空间,看起来就像 Kubeenetes 本身提供的原生功能一样。比如网络插件比较出名的就有 Calico 和 Flannel。

需要强调的是,Kubernetes 的 Node 并不会直接和用户进行交互,它的交互只会通过 Master,用户通过 Master 向节点下发信息。Kubernetes 每个 Node 上,都会运行刚才提到的这几个组件。

总结

为了深入理解各个组件的交互过程,对**「拉起一个Pod的具体过程」**需要有非常细致的了解。

Kubernets基本概念和术语

Master

Master是集群的控制节点,每个K8s集群里需要有一个Master节点来负责整个集群的管理和控制。基本上k8s的所有控制命令都发给它,它来负责整个具体的执行过程。Master节点通常占据一个独立的服务器(高可用部署建议3台服务器)。

Master节点运行着以下一组关键过程:

  • API Server:集群控制的入口进程。
  • k8s Controller Manager:K8s里所有资源对象的自动化控制中心
  • K8s Scheduler:负责资源调度的进程。
  • etcd:所有资源对象的数据全部保存在etcd。

Node

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

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

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

Pod

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 可能的值:

  • 挂起(Pending):Pod 已被 Kubernetes 系统接受,但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间,这可能需要花点时间。
  • 运行中(Running):该 Pod 已经绑定到了一个节点上,Pod 中所有的容器都已被创建。至少有一个容器正在运行,或者正处于启动或重启状态。
  • 成功(Succeeded):Pod 中的所有容器都被成功终止,并且不会再重启。
  • 失败(Failed):Pod 中的所有容器都已终止了,并且至少有一个容器是因为失败终止。也就是说,容器以非0状态退出或者被系统终止。
  • 未知(Unknown):因为某些原因无法取得 Pod 的状态,通常是因为与 Pod 所在主机通信失败。

Labels

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

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

  • 版本标签:“release”,“stable”…
  • 环境标签: “dev”,“pro”…

ReplicationController

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

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

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

Deployment

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

Deployment的使用场景:

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

Service

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

  1. apiVersion: v1
  2. kind:``Service
  3. metadata:
  4. labels:
  5. name: hello
  6. name: hello
  7. spec:
  8. type:``NodePort
  9. ports:
  10. - port:``8080
  11. nodePort:``30008
  12. selector:
  13. name: hello

假设有3个hello Pod运行在3个不同的Node上,客户端访问其中任意一个Node都可以访问到这个服务。

2)LoadBalance

  1. kind:``Service
  2. apiVersion: v1
  3. metadata:
  4. name:``my-service
  5. spec:
  6. selector:
  7. app:``MyApp
  8. ports:
  9. - protocol: TCP
  10. port:``80
  11. targetPort:``9376
  12. nodePort:``30061
  13. clusterIP:``10.0.171.239
  14. loadBalancerIP:``78.11.24.19
  15. type:``LoadBalancer
  16. status:
  17. loadBalancer:
  18. ingress:
  19. - ip:``146.148.47.155

status.loadBalancer.ingress.ip设置的146.148.47.155为云提供商提供的负载均衡器的IP地址,

Volume

默认情况下容器中的磁盘文件是非持久化的,对于运行在容器中的应用来说面临两个问题,第一:当容器挂掉kubelet将重启启动它时,文件将会丢失;第二:当Pod中同时运行多个容器,容器之间需要共享文件时。Kubernetes的Volume解决了这两个问题。

在Docker中也有一个docker Volume的概念 ,Docker的Volume只是磁盘中的一个目录,生命周期不受管理。Kubernetes Volume具有明确的生命周期 - 与pod相同。在容器重新启动时能可以保留数据,当然,当Pod被删除不存在时,Volume也将消失。注意,Kubernetes支持许多类型的Volume,一个Pod可以同时使用任意类型/数量的Volume。

Kubernetes支持Volume类型有:

  • emptyDir 使用emptyDir,当Pod分配到Node上时,将会创建emptyDir,并且只要Node上的Pod一直运行,Volume就会一直存。当Pod(不管任何原因)从Node上被删除时,emptyDir也同时会删除,存储的数据也将永久删除。注:删除容器不影响emptyDir。

示例:

  1. apiVersion: v1
  2. kind:``Pod
  3. metadata:
  4. name: test-pd
  5. spec:
  6. containers:
  7. - image: gcr.io/google_containers/test-webserver
  8. name: test-container
  9. volumeMounts:
  10. - mountPath:``/cache
  11. name: cache-volume
  12. volumes:
  13. - name: cache-volume
  14. emptyDir:``{}
  • hostPath hostPath允许挂载Node上的文件系统到Pod里面去。如果Pod需要使用Node上的文件,可以使用hostPath。示例:
  1. apiVersion: v1
  2. kind:``Pod
  3. metadata:
  4. name: test-pd
  5. spec:
  6. containers:
  7. - image: gcr.io/google_containers/test-webserver
  8. name: test-container
  9. volumeMounts:
  10. - mountPath:``/test-pd
  11. name: test-volume
  12. volumes:
  13. - name: test-volume
  14. hostPath:
  15. # directory location on host
  16. path:``/data

Namespace

Namespace是K8s系统中非常重要的概念,通过将系统内部的对象“分配”到不同Namespace。K8s集群在启动后,会创建一个名为“default”的Namespace。

创建一个名为redis-master的Pod,放入到redis-namespace这个Namespace里。示例:

  1. apiVersion: v1
  2. kind:``Pod
  3. metadata:
  4. name: redis-master
  5. namespace: redis-namespace
  6. spec:
  7. containers:
  8. - name: master
  9. image: kubeguide/redis-master
  10. ports:
    K8s系统中非常重要的概念,通过将系统内部的对象“分配”到不同Namespace。K8s集群在启动后,会创建一个名为“default”的Namespace。

创建一个名为redis-master的Pod,放入到redis-namespace这个Namespace里。示例:

  1. apiVersion: v1
  2. kind:``Pod
  3. metadata:
  4. name: redis-master
  5. namespace: redis-namespace
  6. spec:
  7. containers:
  8. - name: master
  9. image: kubeguide/redis-master
  10. ports:
  11. - containerPort:``6379
这篇关于k8s(Kubernetes)介绍的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!