zoukankan      html  css  js  c++  java
  • kubernetes概述

    一、简介

    1、介绍

    ​ 服务编排工具k8s,kubernetes其实源于希腊语意思(舵手,领航员)。犹豫不太好挤也不太好写,就有了另一个名称叫k8s,kubernetes是谷歌在2014年开始实施的一个项目,当时google已经有了大规模服务容器管理的经验,内部Borg系统,负责对google内部的一些服务进行调度和管理,它的目的是让用户不必操心资源管理的问题,让他们专注自己的核心业务, 并且最大化数据中心的利用率。

    img

    2、什么是k8s

    我们假设有个住户社区,k8s就相当于这个社区的大房东,社区里面有一栋一栋的大楼,大楼可以看做虚拟机器,俗称的VM,大楼里面有很多的住户,每个住户就代表一个pod,那每个住户如何找到他们的位置呢?每个住户如何找到他们的位置就是通过门牌号,我们就理解为IP的位置,在每个住户里面有非常多的家庭成员,爸爸,妈妈,兄弟姐妹,爷爷奶奶,姥爷姥姥,女儿儿子,这些角色就可以理解为container,在这个pod里面的成员,就共享了这个房间里面的资源,水电网络,那些资源就可以把它理解成计算资源,ipu,内存,硬盘。对于大房东k8s,他最主要的功能就是管理,每个住户Pod使用多少资源,那为了就是让整栋大楼,会更有效率的使用很多资源,举例来说:A栋大楼住了太多的住户,太多的Pod,他们直接肯定会相互竞争资源的问题,那它就可以协调某一些pod,就是某一些住户搬到B大楼去,这样会让变得更加的均衡使用。

    • k8s

    官网:https://kubernetes.io/ k8s是一个自动开源系统,自动化部署,扩缩容,管理容器化的应用。
    相比前面的mesos 和swarm,k8s的目的非常的单纯和明确,简单的来说他的目的就是为了服务编排,没有别的。这么明确的明确的目的。虽然目的简单但专注所以专业,非常灵活的使用方式,它考虑到服务服务落地过程中可能遇到的各种各样的问题,各种各样的场景,所以从简单的入手,吃透它。了解它的所有组件,然后回过头看它的架构。

    微信截图_20200909142252.png

    • k8s 集群的样子

    这张图简单的描述了,k8s集群的样子,k8s肯定也需要一个集群,服务调度服务编排肯定要有机器,所以需要集群,中间的七边行是Master节点,可以理解为安装了核心组件的,另外的六边形标识的是Node节点,在k8s里面叫worker节点,然后每个节点里面有个kubelet服务和docker服务,

    Master 负责管理整个集群。 Master 协调集群中的所有活动,例如调度应用、维护应用的所需状态、应用扩容以及推出新的更新。

    Node 是一个虚拟机或者物理机,它在 Kubernetes 集群中充当工作机器的角色 每个Node都有 Kubelet , 它管理 Node 而且是 Node 与 Master 通信的代理。 Node 还应该具有用于处理容器操作的工具,例如 Docker 或 rkt 。处理生产级流量的 Kubernetes 集群至少应具有三个 Node 。

    Master 管理集群,Node 用于托管正在运行的应用。

    在 Kubernetes 上部署应用时,您告诉 Master 启动应用容器。 Master 就编排容器在群集的 Node 上运行。 Node 使用 Master 暴露的 Kubernetes API 与 Master 通信。终端用户也可以使用 Kubernetes API 与集群交互。

    Kubernetes 既可以部署在物理机上也可以部署在虚拟机上。您可以使用 Minikube 开始部署 Kubernetes 集群。 Minikube 是一种轻量级的 Kubernetes 实现,可在本地计算机上创建 VM 并部署仅包含一个节点的简单集群。 Minikube 可用于 Linux , macOS 和 Windows 系统。Minikube CLI 提供了用于引导群集工作的多种操作,包括启动、停止、查看状态和删除。

    多了2个绿色部分,在master里面Deployment。在Node中就是Containerized app就是容器化的应用。图例就是在Master部署了一个Deployment,在三个节点选中了其中的一个部署了应用。Node中的蓝色圆圈标识的是pod。

    pod 是k8s中非常重要的一个概念,所有的应用和服务都是运行在pod里面的,pod是k8s中最小的一个单元,可以理解为k8s的一个原子,pod里面就是容器。

    1. 第一个pod有独立的IP地址,一个容器
    2. 第二个pod有独立的Ip地址,一个容器,一个磁盘存储
    3. 第三个pod有独立的Ip地址,两个容器,一个磁盘存储,这2个容器可以共享IP的,共享网络,共享磁盘的。
    4. 第三个pod有独立的Ip地址,三个容器,2个的磁盘存储,这3个容器可以共享IP的,共享网络,共享磁盘的。

    PS:通过上边的4个小图,可以明白同一个pod里面可以有任意多个容器和存储。

    知道了pod运行了容器,pod自己运行在哪里啊。运行在node,通过kubelet来进行的,调度kuelet把pod运行起来。一个node上面可以运行多个pod。只要资源足够可以建立多个pod。

    3、service

    1. 中间是master节点
    2. 其余的是node节点
    3. 下面的这个node,里面运行了一个pod,pod的外边,有一层虚线,虚线标识service,pod的Ip(10.10.10.1),service(10.10.9.1),service和pod的Ip不同,pod是具体运行在一个node上的,如果pod或者node突然挂掉了,编排工具肯定在其他的node节点下重新起一个pod,这个pod肯定的ip也就变了。所以就需要一个serivce的概念,当pod出问题了,产生一个新的pod,新的pod就是一个新的ip,我们就可以通过service的方式找到pod。
    4. serivce的Ip跟service的生命周期是一致的,如果service不被删除的话,IP一直不发生变化。
    5. 上边这个2个node,三个pod,其实就是从一个实例变成了3个实例,进行了扩容,对外提供想通的服务,这时这个service,ip就有了另外2个作用,除了可以定位pod的地址,可以对pod地址进行负载均衡,进行轮询,

    service的概念基本了解了,怎么确定哪些pod属于一个service,提出一个service的概念,service可能有一个或者是多个pod组成,如何定义service,怎么定义service。在k8s上通过Master的Label Selector的方式,比如s:app=A,s:app=B,有这种标签的确定输入pod等于A 或者pod等于B,所有标签一样的都属于我的小弟。这样service和pod的耦合就非常松。

    PS:(梳理概念)pod里面包括N个容器,service里面包括pod,Deployment可能包括service或者是pod。

    deployment完成应用扩容

    1. Master里面发布了一个Deplyment,想给service 进行扩容
    2. 其实内部是扩容的pod,service只是一个逻辑存在的东西
    3. 把一组pod形成一个逻辑组就是service,扩容完成后,其他两个节点就有了pod实例。
    4. service就开始对外的负载均衡endpoint找到对应的pod

    滚动更新,停掉了一个旧的pod,启动一个新的pod,这时service既有新的,也有旧的存在,直到所有的旧的都更新完毕才结束。所有的更新和扩容的过程serivce的Ip始终是保持不变的。

    二、k8s的整体架构

    首先从整体上看,上边这块就是Master节点,下面有两块都是worker节点,master里面部署的都是k8s的核心模块,虚线框代表的是API Server,提供了资源的核心模块,提供了认证授权和k8s的访问控制,可以通过kubectl或者自己开发的userClient,restApi的形式访问API server。从而完成整个集群的访问。

    1. ControllerManager负责维护集群的状态,比如故障检测,扩缩容,滚动更新等等。
    2. Scheduler负责资源的调度,按照预定的策略把pod调度到指定的node节点
    3. ETCD 用做已执行存储,pod,service的集群等信息,k8s需要持久化的数据都存储在这个上边。
    4. Kubelet负责维护当前节点上的容器的生命和volumes,网络。
    5. 每个Node上可以运行一个kube-proxy,负责service 提供内部的服务发现和负载均衡,为service方法做个落地的功能。
    6. kube-dns负责整个集群的dns服务,这个组件不是必须的,一般通过名字访问比较方便。
    7. dashboard集群数据的GUI界面。

    PS:全过程梳理

    1. kubectl 发起一个请求,请求经过认证。
    2. scheduler的策略和评分计算得到目标的node。
    3. APIServer请求Node,通过kublet把这个Node运行pod起来。
    4. APIServer把信息发送给ETCD保存起来。
    5. pod运行起来之后,通过ControllerManager管理每个pod的状态,如果突然挂了,就想办法创建一个pod。给pod分个独立的ip地址,可以在整个集群内使用这个ip来访问它。但是pod的ip是易变的,异常重启和升级的时候,不可能关注某个pod的Ip的。
    6. 下面虚线的部分表示的是一个service,service里面有3个pod,不在虚线里面的是单独存在的pod,并没有提供service的入口,完成service的具体工作的模块就是kube-proxy,在每个node上都有一个kube-proxy,然后给service分配一个ip,可以访问service里面的pod,所以kube-proxy对应的service都会有一个ip的指向,负载均衡的访问他们。
    7. kube-proxy(service) 可以把端口和ip直接暴露在node上。外边的请求可以访问node上的ip就可以关联到这个service上了。
    8. kube-dns 就是为了方便名字直接访问node节点。任何一个pod都可以通过名字来进行访问。

    三、k8s的设计理念

    了解设计理念可以更深入的了解k8s,设计实在太好了,非常值得我们学习和借鉴。

    • API设计原则
    1. 所有的api都是声明式的(对于重复的操作是稳定的,所有的对象都是名词,不是动词,用户很容易的期望用户的样子,当前的系统是否满足需求,明确用户的目的,用系统管理的业务意图触发设计)
    2. 控制机的设计原则(假定各种可能存在错误的可能,并做容错处理,出现局部错误和临时错误是很正常的事情,错误可能存在于物理故障磁盘,外部系统的故障啊,系统本身的代码问题,考虑到任何可能的错误,并且做容错处理,每个模块出现错误后,恢复处理,在系统中不可能保证每个模块始终是连接的,因此任何一个模块都要有自动修复的能力,保证连接不到其他模块而形成的自我崩溃。很多情况下可以做到优雅的降级,要求在设计的过程中,有基本功能和高级功能,同时不会导致高级功能的崩溃,影响到这个模块 的使用,更容易的引入高级功能,而会导致高级功能影响基本功能。)
    • k8s网络
    1. CNI
    2. Flannel,Calico,Weave
    3. Pod网络
    • scheduler-preselect
    1. NodiskConflict 挂载冲突
    2. checkNodeMemMemoryPressure 内存的压力
    3. Nodeselect 节点的选择器
    4. FitRescoure CPU,内存的限制
    5. Affinity 满足pod的连接状态的限制
    • scheduler-optimize-select

    优先规则,对node进行打分,通过优先函数进行预选规则,每个优先函数可以返回0-10的函数,分数越高,这台主机越适合,对应一个权重。

    1. selectorSpreadPriority
    2. LeastRequestedPriority
    3. AffinityPriority
    • pod内部通讯

    • 同一个node上的不同pod通讯

    通过pod的Ip来进行访问

    • 不同的node,不同的pod通讯

    满足pod,ip不能冲突

    四、k8s的服务发现

    • kube-proxy(ClusterIp)

    每个服务,所有的pod给虚拟Ip,虚拟Ip只能在内部访问

    • kube-proxy(NodePort)

    服务暴露到节点,外部的可以通过NodeIp 访问pod

    • kube-DNS

    负责集群内部的dns解析,内部之间可以通过名称访问pod。

    参考:

    https://kubernetes.io/zh/docs/tutorials/kubernetes-basics/

    https://idig8.com/

  • 相关阅读:
    《应用Yii1.1和PHP5进行敏捷Web开发》学习笔记(转)
    YII 小模块功能
    Netbeans代码配色主题大搜集
    opensuse 启动巨慢 解决方法 90s多
    opensuse 安装 网易云音乐 rpm netease music
    linux qq rpm deb opensuse
    openSUSE 安装 alien
    第一行代码 Android 第2版
    Android Studio AVD 虚拟机 联网 失败
    docker error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.29/containers/json: open //./pipe/docker_engine: The system cannot find the file specified. In the default daemon configuratio
  • 原文地址:https://www.cnblogs.com/mengw/p/13639943.html
Copyright © 2011-2022 走看看