美文网首页思科ACI思科DevNetk8s
K8s介绍以及运行架构

K8s介绍以及运行架构

作者: TimLi_51bb | 来源:发表于2020-12-01 16:49 被阅读0次

    Kubernetes(k8s)是Google开源的容器集群管理系统。在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。

    Kubernetes最主要的设计思想是,从更宏观的角度,以统一的方式来定义任务之间的各种关系,并且为将来支持更多种类的任务留足余地。

    Kubernetes所擅长的,是按照用户的意愿和整个系统的规则,完全自动化地处理好容器之间的各种关系。这种功能,就是我们经常听到的一个概念:编排。所以说,Kubernetes的本质,是为用户提供一个具有普遍意义的容器编排工具。

    k8s中几个重要概念

    (1) Cluster,Cluster是 计算、存储和网络资源的集合,k8s利用这些资源运行各种基于容器的应用。

    (2) Master, Master是cluster的大脑,他的主要职责是调度,即决定将应用放在那里运行。master运行linux操作系统,可以是物理机或者虚拟机。为了实现高可用,可以运行多个master。

    (3) Node, Node的职责是运行容器应用。node由master管理,node负责监控并汇报容器的状态,同时根据master的要求管理容器的生命周期。node运行在linux的操作系统上,可以是物理机或者是虚拟机。

    (4),pod,pod是k8s的最小工作单元。每个pod可以包含一个或者多个容器。pod中的容器会作为一个整体被master调度到一个node上运行。 Pod有两种使用方式,运行单一容器和运行多个容器, 运行单一容器是Kubernetes 最常见的模型,即便是只有一个容器,Kubernetes 管理的也是Pod 而不是直接管理容器。而pod中运行多个容器的话,哪些容器应该放到一个Pod中?答案是:这些容器联系必须非常紧密,而且需要直接共享资源。

    (5)controller, k8s不会直接创建pod,而是通过controller来管理pod的。controller中定义了pod的部署特性,比如有几个副本,在什么样的node上运行等。为了满足不同的业务场景,k8s提供了多种controller,包括Replication Controller(RC)、Replica Set(RS)、Deployment 、daemonset、statefulset、job等。

    RC是K8s集群中最早的保证Pod高可用的API对象,通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个;少于指定数目,RC就会启动运行新的Pod副本;多于指定数目,RC就会杀死多余的Pod副本。即使在指定数目为1的情况下,通过RC运行Pod也比直接运行Pod更明智,因为RC也可以发挥它高可用的能力,保证永远有1个Pod在运行。

    (6)Replica Set (RS)

    RS是新一代RC,提供同样的高可用能力,区别主要在于RS后来居上,能支持更多种类的匹配模式。RS对象一般不单独使用,而是作为Deployment的理想状态参数使用。使用deployment时会自动创建Replica Set ,也就是说deployment是通过Replica.Set来管理pod的多个副本的,我们通常不需要直接使用Replica Set 。

    (7) deployment(部署)

    Deployment表示用户对K8s集群的一次更新操作,它是一个比RS应用模式更广的API对象,可以是创建一个新的服务,更新一个新的服务,也可以是滚动升级一个服务。以K8s的发展方向,未来对所有长期伺服型的的业务的管理,都会通过Deployment来管理。

    (8) daemonset(后台支撑型服务)

    长期伺服型和批处理型服务的核心在业务应用,可能有些节点运行多个同类业务的Pod,有些节点上又没有这类Pod运行;而后台支撑型服务的核心关注点在K8s集群中的节点(物理机或虚拟机),要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点选定的一些特定节点。典型的后台支撑型服务包括,存储,日志和监控等在每个节点上支持K8s集群运行的服务。

    (9) statefuleset

    能够保证pod的每个副本在整个生命周期中名称是不变的,而其他controller不提供这个功能。当某个pod发生故障需要删除并重新启动时,pod的名称不会发生变化,同时statefulset会保证副本按照固定的顺序启动、更新或者删除。、

    (10) job 用于运行结束就删除的应用,而其他controller中的pod通常是长期持续运行的。

    (11) service, deployment可以部署多个副本,每个pod 都有自己的IP,外界如何访问这些副本那?答案是service。

    k8s的service定义了外界访问一组特定pod的方式。service有自己的IP和端口,service为pod提供了负载均衡。

    k8s运行容器pod与访问容器这两项任务分别由controller和service执行。

    (12)、namespace

    可以将一个物理的cluster逻辑上划分成多个虚拟cluster,每个cluster就是一个namespace。不同的namespace里的资源是完全隔离的。Kubernetes 默认创建了两个

    Kubernetes 默认创建了两个,Namespace。default -- 创建资源时如果不指定,将被放到这个

    Namespace 中。kube-system:Kubernetes 自己创建的系统资源将放到这个Namespace 中

    1、k8s中master的组成

    (1) API, Server(kube-apiserver),API Server是k8s的前端接口,各种客户端工具以及k8s其他组件可以通过它管理集群的各种资源。

    (2) Scheduler(kube-scheduler),scheduer负责决定将pod放在哪个node上运行。另外scheduler在调度时会充分考虑集群的架构,当前各个节点的负载,以及应用对高可用、性能、数据亲和性的需求。

    (3) Controller,Manager(kube-controller-manager),负责维护集群的状态,比如故障检测、自动扩展、滚动更新等。Controller

    Manager 由多种 controller组成,包括 replication controller、endpoints,controller、namespace,controller、serviceaccounts controller 等。

    不同的 controller管理不同的资源。例如 replication controller 管理 Deployment、StatefulSet、DaemonSet 的生命周期,namespace controller 管理 Namespace资源。

    (4)etcd

    负责保存k8s集群的配置信息和各种资源的状态信息,K8S中所有的服务节点的信息数据、配置数据都是存储在ETCD中,当数据发生变化时,etcd会快速的通知k8s相关组件。

    (5)pod网络(flannel )

    pod要能够相互通信,k8s集群必须掌握pod网络,flannel是其中一个可选的方案。

    k8s中node的组成

    (1)kubelet,  是node的agent,当scheduler去确定在某个node上运行pod后,会将pod的具体配置信息发送给该节点的kubelet,kubelet会根据这些信息创建和运行容器,并向master报告运行状态。

    (2)kube-proxy, service 在逻辑上代表了后端的多个 Pod,外界通过service 访问 Pod。service接收到的请求是如何转发到 Pod 的呢?这就是kube-proxy要完成的工作。proxy是配合service实现从pod到service, 以及从外部的node  port到service的访问。每个 Node都会运行 kube-proxy 服务,它负责将访问 service 的 TCP/UPD,数据流转发到后端的容器。如果有多个副本,kube-proxy会实现负载均衡。

    (3)pod网络, pod能能够互相通信,k8s集群必须部署pod网络,flannel是其中一个可以选择的方案

    1.   kubectl发送部署deployment的请求到API Server。

    2、API Server通知Controller Manager创建一个deployment资源。

    3、Deployment controller向API Server发送创建ReplicaSet的需求。

    4、ReplicaSet通知ReplicaSet controller启动。

    5、ReplicaSet controller发送创建Pod需求到API Server

    6、API Server通知Scheduler执行调度任务

    7、Scheduler根据副本数将分配Pod到集群中的node节点

    8、API Server通知对应的node节点上面的kubelet组件准备创建pod

    9、kubelet告诉docker在本节点上运行容器。

    10、docker在节点上运行一个或多个容器。

    Deployment 的概念

    作为最常用的Kubernetes对象,Deployment经常会用来创建 ReplicaSet和Pod,我们往往不会直接在集群中使用ReplicaSet部署一个新的微服务,一方面是因为ReplicaSet 的功能其实不够强大,一些常见的更新、扩容和缩容运维操作都不支持,Deployment的引入就是为了支持这些复杂的操作

    Deployment 执行流程总结

    最后,总结一下deployment实现的过程:

    (1)首先用户通过 kubectl 创建Deployment。

    (2)接着,Deployment创建 ReplicaSet。

    (3)然后,ReplicaSet 创建Pod

    (4)最后,pod在每个节点上通过kubelet调用docker完成容器创建。

    这个工作就变成了一个挑战,而且全部停止了服务,再逐步升级的方式会导致服务较长时间不可用。针对这个问题,k8s提供了滚动更新(rolling-update)的方式来解决上述问题。滚动更新是针对pod来操作的,它通过一次只更新一小部分副本,成功后,再更新更多的副本,最终完成所有副本的更新。滚动更新的最大的好处是零停机,整个更新过程始终有副本在运行,从而保证了服务的连续性。

    Docker使用Google公司推出的Go语言进行开发实现,基于Linux内核的 cgroup,namespace,对进程进行封装隔离,属于操作系统层面的虚拟化技术。由于隔离的进程独立于宿主机和其它隔离的进程,因此也称其为容器。

    Docker在容器的基础上,进行了进一步的封装,从文件系统、网络互联到进程隔离等等,极大的简化了容器的创建和维护。使得Docker技术比虚拟机技术更为轻便、快捷

    Docker 包括三个基本概念

    Øl  镜像(Image)

    操作系统分为内核和用户空间。对于Linux而言,内核启动后,会挂载root文件系统为其提供用户空间支持。而 Docker 镜像(Image),就相当于是一个 root文件系统。比如官方镜像centos:latest 就包含了完整的一套centos:latest最小系统的root文件系统。 Docker镜像是一个特殊的文件系统,除了提供容器运行时所需的程序、库、资源、配置等文件外,还包含了一些为运行时准备的一些配置参数(如匿名卷、环境变量、用户等)。

    容器(Container)

     镜像(Image)和容器(Container)有紧密的关系,镜像是静态的定义,容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。容器的实质是进程,但与直接在宿主执行的进程不同,容器进程运行于属于自己的独立的命名空间。因此容器可以拥有自己的root文件系统、自己的网络配置、自己的进程空间,甚至自己的用户ID空间。

    (1)Docker

    Registry,镜像构建完成后,可以很容易的在当前宿主机上运行,但是,如果需要在其它服务器上使用这个镜像,我们就需要一个集中的存储、分发镜像的服务,Docker Registry 就是这样的服务。一个 Docker Registry 中可以包含多个仓库(Repository);每个仓库可以包含多个标签(Tag);每个标签对应一个镜像。通常,一个仓库会包含同一个软件不同版本的镜像,而标签就常用于对应该软件的各个版本。我们可以通过。<仓库名>:<标签> 的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签,将以 latest 作为默认标签。

    默认容器的数据是保存在容器的可读写层,当容器被删除时其上的数据将会丢失,所以为了实现数据的持久性则需要选择一种数据持久技术来保存数据,当前有以下二种方式:

    ØØ  数据卷(Volumes)

    ØØ  挂载主机目录(Bind mounts)

     Volumes方式下:容器内的数据被存放到宿主机(linux)一个特定的目录下(/var/lib/docker/volumes/)。这个目录只有Docker可以管理,其他进程不能修改。如果想持久保存容器的应用数据,Volumes是Docker推荐的挂载方式。

     Bind mounts方式下:容器内的数据被存放到宿主机文件系统的任意位置,甚至存放到一些重要的系统目录或文件中。除了Docker之外的进程也可以任意对他们进行修改;

    理解 docker build 的工作原理。

    Docker 在运行时分为 Docker 引擎(也就是服务端守护进程)和客户端工具。Docker 的引擎提供了一组 REST API,被称为 Docker Remote API,而如 docker 命令这样的客户端工具,则是通过这组 API 与 Docker 引擎交互,从而完成各种功能。

    当我们进行镜像构建的时候,并非所有定制都会通过RUN指令完成,经常会需要将一些本地文件复制进镜像,比如通过 COPY 指令、ADD指令等。而 docker build命令构建镜像,其实并非在本地构建,而是在服务端,也就是Docker引擎中构建的。那么在这种客户端/服务端的架构中,如何才能让服务端获得本地文件呢?

    这就引入了上下文的概念。当构建的时候,用户会指定构建镜像上下文的路径,docker build命令得知这个路径后,会将路径下的所有内容打包,然后上传给Docker引擎。这样Docker引擎收到这个上下文包后,展开就会获得构建镜像所需的一切文件。

    实际上Dockerfile的文件名并不要求必须为Dockerfile,而且并不要求必须位于上下文目录中,比如可以用-f参数指定某个文件作为Dockerfile,当然,一般大家习惯性的会使用默认的文件名 Dockerfile,以及会将其置于镜像构建上下文目录中。

    相关文章

      网友评论

        本文标题:K8s介绍以及运行架构

        本文链接:https://www.haomeiwen.com/subject/vzojwktx.html