• 1 Kubernetes管理之master和Node


    Kubernetes中的大部分概念如NodePodReplication ControllerService等都可以看作一种“资源对象”,几乎所有的资源对象都可以通过Kubernetes提供的kubectl工具(或者API编程调用)执行增、删、改、查等操作并将其保存在etcd中持久化存储。从这个角度来看,Kubernetes其实是一个高度自动化的资源控制系统,它通过跟踪对比etcd库里保存的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制和自动纠错的高级功能。

    在介绍资源对象之前,我们先了解一下Kubernetes集群的两种管理角色:MasterNode

    Master

    Kubernetes里的Master指的是集群控制节点,每个Kubernetes集群里需要有一个Master节点来负责整个集群的管理和控制,基本上Kubernetes的所有控制命令都发给它,它来负责具体的执行过程,我们后面执行的所有命令基本都是在Master节点上运行的。Master节点通常会占据一个独立的服务器(高可用部署建议用3台服务器),其主要原因是它太重要了,是整个集群的“首脑”,如果宕机或者不可用,那么对集群内容器应用的管理都将失效。

    Master节点上运行着以下一组关键进程。

    • Kubernetes API Server (kube-apiserver):提供了 HTTP Rest 接口的关键服务进程,是Kubernetes里所有资源的增、删、改、查等操作的唯一入口,也是集群控制的入口进程。

    • Kubernetes Controller Manager (kube-controller-manager):Kubernetes里所有资源对象的自动化控制中心,可以理解为资源对象的“大总管”。

    • Kubernetes Scheduler (kube-scheduler):负责资源调度(Pod调度)的进程,相当于公交公司的“调度室”。

    另外,在Master节点上还需要启动一个etcd服务,因为Kubernetes里的所有资源对象的数据全部是保存在etcd中的。

    Node

    除了Master,Kubernetes集群中的其他机器被称为Node节点,在较早的版本中也被称为Minion。与Master一样,Node节点可以是一台物理主机,也可以是一台虚拟机。Node节点才是Kubernetes集群中的工作负载节点,每个Node都会被Master分配一些工作负载(Docker容器),当某个Node宕机时,其上的工作负载会被Master自动转移到其他节点上去。

    每个Node节点上都运行着以下一组关键进程。

    • kubelet:负责Pod对应的容器的创建、启停等任务,同时与Master节点密切协作,实现集群管理的基本功能。
    • kube-proxy:实现Kubernetes Service的通信与负载均衡机制的重要组件。
    • Docker Engine (docker):Docker引擎,负责本机的容器创建和管理工作。

    Node节点可以在运行期间动态增加到Kubernetes集群中,前提是这个节点上已经正确安装、配置和启动了上述关键进程,在默认情况下kubelet会向Master注册自己,这也是Kubernetes推荐的Node管理方式。一旦Node被纳入集群管理范围,kubelet进程就会定时向Master节点汇报自身的情报,例如操作系统、Docker版本、机器的CPU和内存情况,以及当前有哪些Pod在运行等,这样Master可以获知每个Node的资源使用情况,并实现高效均衡等资源调度策略。而某个Node超过指定时间不上报信息时,会被Master判断为“失联”,Node的状态被标记为不可用(Not Ready),随后Master会触发“工作负载大转移”的自动流程。

    我们可以执行下述命令查看集群中有多少个Node:

    # kubectl get nodes
    NAME        STATUS    AGE
    127.0.0.1   Ready     1d
    

    然后,通过kubectl describe node <node_name>来查看某个Node的详细信息:

    # kubectl describe node 127.0.0.1
    
    Name:           127.0.0.1
    Role:           
    Labels:         beta.kubernetes.io/arch=amd64
                beta.kubernetes.io/os=linux
                kubernetes.io/hostname=127.0.0.1
    Taints:         <none>
    CreationTimestamp:  Mon, 02 Jul 2018 10:11:27 +0800
    Phase:          
    Conditions:
      Type          Status  LastHeartbeatTime           LastTransitionTime          Reason      Message
      ----          ------  -----------------           ------------------          ------      -------
      OutOfDisk         False   Tue, 03 Jul 2018 15:10:49 +0800     Mon, 02 Jul 2018 10:11:27 +0800     KubeletHasSufficientDisk    kubelet has sufficient disk space available
      MemoryPressure    False   Tue, 03 Jul 2018 15:10:49 +0800     Mon, 02 Jul 2018 10:11:27 +0800     KubeletHasSufficientMemory  kubelet has sufficient memory available
      DiskPressure      False   Tue, 03 Jul 2018 15:10:49 +0800     Mon, 02 Jul 2018 10:11:27 +0800     KubeletHasNoDiskPressure    kubelet has no disk pressure
      Ready         True    Tue, 03 Jul 2018 15:10:49 +0800     Mon, 02 Jul 2018 10:11:38 +0800     KubeletReady    kubelet is posting ready status
    Addresses:      127.0.0.1,127.0.0.1,127.0.0.1
    Capacity:
     alpha.kubernetes.io/nvidia-gpu:    0
     cpu:                   1
     memory:                1883844Ki
     pods:                  110
    Allocatable:
     alpha.kubernetes.io/nvidia-gpu:    0
     cpu:                   1
     memory:                1883844Ki
     pods:                  110
    System Info:
     Machine ID:            f9d400c5e1e8c3a8209e990d887d4ac1
     System UUID:           13C940BE-9125-4594-9C8B-82E19C997FF3
     Boot ID:           09a9b2bf-14cf-4e32-a724-8b279d44a387
     Kernel Version:        3.10.0-514.26.2.el7.x86_64
     OS Image:          CentOS Linux 7 (Core)
     Operating System:      linux
     Architecture:          amd64
     Container Runtime Version: docker://1.13.1
     Kubelet Version:       v1.5.2
     Kube-Proxy Version:        v1.5.2
    ExternalID:         127.0.0.1
    Non-terminated Pods:        (3 in total)
      Namespace         Name            CPU Requests    CPU Limits  Memory Requests Memory Limits
      ---------         ----            ------------    ----------  --------------- -------------
      default           mysql-pgb63     0 (0%)      0 (0%)      0 (0%)      0 (0%)
      default           myweb-c994c     0 (0%)      0 (0%)      0 (0%)      0 (0%)
      default           myweb-jgcqn     0 (0%)      0 (0%)      0 (0%)      0 (0%)
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.
      CPU Requests  CPU Limits  Memory Requests Memory Limits
      ------------  ----------  --------------- -------------
      0 (0%)    0 (0%)      0 (0%)      0 (0%)
    No events.
    

    上述命令展示了Node的如下关键信息。

    • Node基本信息:名称、标签、创建时间等。

    • Node当前的运行状态,Node启动以后会做一系列的自检工作,比如磁盘是否满了,如果满了就标注OutOfDisk=True,否则继续检查内存是否不足(如果内存不足,就标注MemoryPressure=True),最后一切正常,就设置为Ready状态(Ready=True),该状态表示Node处于健康状态,Master将可以在其上调度新的任务了(如启动Pod)。

    • Node的主机地址与主机名。

    • Node上的资源总量:描述Node可用的系统资源,包括CPU、内存数量、最大可调度Pod数量等,注意到目前Kubernetes已经实验性地支持GPU资源分配了(alpha.kubernetes.io/nvidia-gpu=0)。

    • Node可分配资源量:描述Node当前可用于分配等资源量。

    • 主机系统信息:包括主机等唯一标识UUID、Linux kernel版本号、操作系统类型与版本、Kubernetes版本号、kubelet与kube-proxy的版本号等。

    • 当前正在运行等Pod列表概要信息。

    • 已分配的资源使用概要信息,例如资源申请的最低、最大允许使用量占系统总量等百分比。

    • Node相关的Event信息。

    转载自 https://www.orchome.com/1333

     


  • 相关阅读:
    如何回答十个最棘手的面试问题(下)
    数据库设计三大范式应用实例剖析
    也谈内置无线网卡
    用10个漂亮问题完美结束面试
    Visual C++6.0编译器报错fatal error C1083
    MSDN library下载地址
    如何回答十个最棘手的面试问题(上)
    个人计划永不乱:五款定时提醒软件横评
    怎样使用C#调用exe的应用程序
    组策略妙用通过组策略禁止域用户更改IP地址
  • 原文地址:https://www.cnblogs.com/linux20190409/p/10976168.html
Copyright © 2020-2023  润新知