精华内容
下载资源
问答
  • node节点flannel网络问题导致该node上的pod与其他node节点网络不通的排查思路与解决方法 一、问题发现 在部署一个replicas:4的nginx deployment之后在master节点通过curl + podIP + 端口的形式测试时,发现两次访问...

    node节点flannel网络问题导致该node上的pod与其他node节点网络不通的排查思路与解决方法

    一、问题发现

    在部署一个replicas:4的nginx deployment之后在master节点通过curl + podIP + 端口的形式测试时,发现两次访问不到,两次可以访问得到。

    二、问题排查

    1、通过ping pod的ip地址,发现node1节点的pod全都ping不通,问题很有可能就出在node1节点上

    2、通过ip a查看node1节点发现flannel.1没有ip地址,可能原因就出现在这。

    3、刚开始以为是iptables规则可能导致节点flannel网络没起来,于是就把iptables规则全清了,重启了kubelet后发现还是没有flannel网络。

    4、然后在master节点通过kubectl logs -f -n kube-system kube-flannel的Pod来查看对应node1的flannel Pod的日志发现一个错误日志,还是网络down掉了

    failed to add vxlanRoute (10.244.0.0/24 -> 10.244.0.0): network is down

    5、尝试将node1节点的flannel.1网络删除,在node1节点上执行

    ip link delete flannel.1
    

    6、在 /etc/sysctl.conf 中 设置 net.ipv4.ip_forward=1,开启路由功能。

    7、将node1的网卡重启

    systemctl restart network
    

    8、在master节点上删掉flannel的Pod,重新启动flannel的yaml文件

    kubectl delete -f kube-flannel.yml
    kubectl apply -f kube-flannel.yml
    

    9、通过ip a查看node1节点的IP,发现flannel.1果然有IP地址了

    flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default
    link/ether ce:86:ca:01:e0:3f brd ff:ff:ff:ff:ff:ff
    inet 10.244.1.0/32 scope global flannel.1
    valid_lft forever preferred_lft forever

    10、在master节点ping node1节点上的Pod发现可以ping通,通过kubectl exec -it dep-with-healthycheck-55f68fd487-d /bin/bash 命令进入其中的一个pod使用

    curl -I 10.244.2.90命令测试与其他Pod通不通,发现也是通的。

    [root@master test]# kubectl exec -it dep-with-healthycheck-55f68fd487-df2xm /bin/bash
    root@dep-with-healthycheck-55f68fd487-df2xm:/# curl -I 10.244.2.90
    HTTP/1.1 200 OK
    Server: nginx/1.19.1
    Date: Sun, 02 Aug 2020 14:54:11 GMT
    Content-Type: text/html
    Content-Length: 612
    Last-Modified: Tue, 07 Jul 2020 15:52:25 GMT
    Connection: keep-alive
    ETag: “5f049a39-264”
    Accept-Ranges: bytes

    至此,问题解决,记录一下,以作参考

    展开全文
  • kubernetes的node 节点管理

    千次阅读 2018-07-10 17:45:34
    node节点上运行一些服务用来运行pod以及与master通信等。一个node上的服务包括docker运行时环境、kubelet、kube-proxy以及其它一些可选的add-ons。节点状态node的状态包含如下几个方面的信息:...

    原文:https://kubernetes.io/docs/concepts/architecture/nodes/

    node是kubernetes集群中的工作节点,可以是虚拟机也可以是物理机。node节点上运行一些服务用来运行pod以及与master通信等。一个node上的服务包括docker运行时环境、kubelet、kube-proxy以及其它一些可选的add-ons。

    节点状态

    node的状态包含如下几个方面的信息:

    • Addresses
    • Condition
    • Capacity
    • Info

    Addresses

    节点的地址信息由node的配置决定,包含如下三项:

    • HostName:同node内核决定的主机名,可以由kubelet的--hostname-override选项覆盖。
    • ExternalIP:外网访问IP。
    • InternalIP:内网IP,集群内部的私有地址。

    Conditions

    Conditions描述所有处于RUNNING状态的节点信息。

    Node ConditionDescription
    OutOfDiskTrue if there is insufficient free space on the node for adding new pods, otherwise False
    ReadyTrue if the node is healthy and ready to accept pods, False if the node is not healthy and is not accepting pods, and Unknown if the node controller has not heard from the node in the last node-monitor-grace-period (default is 40 seconds)
    MemoryPressureTrue if pressure exists on the node memory – that is, if the node memory is low; otherwise False
    PIDPressureTrue if pressure exists on the processes – that is, if there are too many processes on the node; otherwise False
    DiskPressureTrue if pressure exists on the disk size – that is, if the disk capacity is low; otherwise False
    NetworkUnavailableTrue if the network for the node is not correctly configured, otherwise False
    ConfigOKTrue if the kubelet is correctly configured, otherwise False

    关键问题是以上这些信息是如何计算判定的呢?

    Node的conditions用json对象表示,如以下应答表示健康的node:

    "conditions": [
      {
        "type": "Ready",
        "status": "True"
      }
    ]

    如果节点的Ready condition是“Unknown” 或者 “False”,kube-controller-manager则将这个节点标记为不可用状态。节点上所有的pod被Node Controller调度排除,默认的排除超时时间是5分钟。有时节点因为网络原因不可达,kubernetes的控制面无法与节点上的kubelet建立联系,删除pod的指令无法下发到kubelet上,则可能的情况是控制面一直试图联系失联节点直到通信恢复,在此期间在此失联节点上的pod一直持续运行。

    在kubernetes1.5及以前版本中,node controller可能会强制从系统中删除不可达的pod。但是,在1.5及更高的版本中,node controller直到明确确认这些pod停止运行后才会将它们从系统记录中删除,也就是说node controller必需明确知道pod的状态如“Terminating” 或者 “Unknown”。对于永久失联的node,kubernetes无法确定这个node是暂时失联稍后恢复还是永久从集群中删除,在这种情况下需要管理员手动删除node对象,删除node会引发kubernetes删除节点上的所有pod,并且释放它们所占用的名称。

    从1.8版本开始介绍了一种新的测试特性,就是自动创建taints表示conditions。要想打开这种特性,需要给API server、controller manager、scheduler传递一个开关:--feature-gates=...,TaintNodesByCondition=true。当TaintNodesByCondition被打开后,scheduler在调度时就会忽略掉节点的conditions,代之以查看节点的taints与pod的tolerations。
    现在用户可以在旧的调度模式与新的调度模式,一种更灵活的调度模式之间作出选择。对于没有任何tolerations的pod使用旧的调度模式,但是,如果pod能够容忍在特定节点上被污染的话,就会被调度到那个特定节点上。

    需要注意:node的condition被观测到taints被创建的时间跨度,通常小于1秒,因为这种时间延迟,有可能会轻微的增加pod被成功调度出去,但是kubelet却拒绝接收的情况。

    Capacity

    描述节点的可用资源:CPU、内在以及其上可以调度的最大的pod数等。

    Info

    节点常规信息,如内核版本、kubernetes版本,docker版本、操作系统名称等。这些信息由节点上的kubelet提供。

    节点管理

    node不同于pod、service等kubernetes内部创建的对象,它是由外部创建。当在kubernetes内部创建node时,只是在kubernetes内部创建一个表示已经存在节点的对象。创建完以后kubernetes会检查节点是否可用,比如创建了如下节点:

    {
      "kind": "Node",
      "apiVersion": "v1",
      "metadata": {
        "name": "10.240.79.157",
        "labels": {
          "name": "my-first-k8s-node"
        }
      }
    }

    kubernetes由提供的信息在内部创建一个代表节点的node对象,然后对节点执行可用性检查,如必需的服务是否在正常运行,是否具备运行pod的资格。如果不可用则不让这个节点参与任何集群活动。系统会保留不可用node并且持续监控它的状态,直到它可用为止,或者是用户明确删除创建的node对象。

    目前,有三个组件会与kubernetes的node接口交互:node controller, kubelet, and kubectl。

    节点控制器

    Node controller是kubernetes控制面中的一个组件,负责管理node的方方面面。

    在node的整个生命周期中,node controller充当多种角色,首先在node注册入集群时为它分配一个CIDR地址块(如果此特性打开的话)。

    第二个是维护node controller内部的可用节点列表,并与低层的云供商的可用节点的列表保持一致。当运行在云环境中时,如果node controller检测到某个节点不健康,它就会向供应商询问节点虚拟机是否可用,如果不可用就从列表删除。

    第三个是监控节点的健康状态。Node controller检测到node不可达时,负责将node状态中的NodeReady condition更新到ConditionUnknown,然后将node上的所有pod排除(如果节点不可达的时候超过40s(默认值),会被标记成ConditionUnknown,此时并没有发生排除pod的动作,系统试图重新联系不可达的node,如果恢复的话则node重新被标记成NodeReady。如果不可达的时间超过5分钟(默认值)才会采取排除步骤)。系统每隔--node-monitor-period设置的秒数检测一次节点的状态。

    在kubernetes1.4中,改善了node controller处理集群中node数过多的逻辑。从1.4开始,node controller在决定是否排除pod之前,先检测一次集群中所有node的状态。

    在多数情况下,node controller通过--node-eviction-rate的设定值限制了排除pod的速率,默认是0.1次每秒,意思是对于单个node,排除的速率小于10秒一次。

    当node在一个可用的zone变得不健康时,node的排除行为会发生改变,也就是说排除行为并不是一成不变。Node controller检测在zone内不健康node的百分数,如果不健康node的比例低于--unhealthy-zone-threshold (default 0.55),那么排除速率将会降低:如果集群规模小(node数小于或者等于--large-cluster-size-threshold,默认50),则排除行为终止,则否,排除速率将会降低到--secondary-node-eviction-rate(默认0.01)每秒。如此策略的主要原因主要是为在将一个可用的zone分区时提供一种过渡缓冲。如果你的集群没有跨多个云供应商的话,那么你只有一个可用的zone,就是整个集群。

    将node分布在不同可用zone的主要原因是当一个zone整体不能用时,可以将workload切换到另一个可用的zone。所以当一个zone不可用时,kubernetes以正常速率排除。极端情况下,如果所有zone都不可用,那么kubernetes假定master之间的联通性出现了问题,停止一切排除行为直到master之间的联通性恢复。

    从1.6版本开始,当pod不容忍taints时,node controller也负责排除运行在node上的NoExecute taints,这是一个测试特性,默认禁止。Node controller负责添加与node问题对应的taint,比如不可达。

    从1.8版本开始,node controller能够被用来创建表示node conditions的taint,这是1.8版本的一个测试特性。

    自注册节点

    当node中kubelete的标志--register-node被设置成true时,kubelete尝试主动注册自已到系统中。这是一种被大多数distros使用的比较好的模式。本质是是由kubelete在系统中创建node对象而非用户手动。

    自注册node的kubelet需要指定如下几个启动参数:

    • --kubeconfig - Path to credentials to authenticate itself to the apiserver.
    • --cloud-provider - How to talk to a cloud provider to read metadata about itself.
    • --register-node - Automatically register with the API server.
    • --register-with-taints - Register the node with the given list of taints (comma separated <key>=<value>:<effect>). No-op if register-node is false.
    • --node-ip - IP address of the node.
    • --node-labels - Labels to add when registering the node in the cluster.
    • --node-status-update-frequency - Specifies how often kubelet posts node status to master.

    目前kubelete被授权任意创建node对象,但在被际操作中它只创建、修改它自己。在将来的版本中计划将kubelete的授权收缩,使它只能创建、修改它自己。

    手动管理node

    集群管理员可以手动创建、修改node对象,当然先要把node的自注册功能关掉,设置node的kubelete标志--register-node=false。

    用户可以手动设置node标签、或者使node不可以被安排调度。

    标签可以被node selectors用来聚合node从而控制调度,比如约束pod只能调度到符合条件的node上。

    使node不可调度,可以阻止node授受新的调度任务,对已经存在的pod没有影响。这个特性很有用。使node不可调度可运行如下命令:

    kubectl cordon $NODENAME

    注意,使node不可调度,对DaemonSet类型的pod无效。

    Node capacity

    Node的capacity也是node对象的一部分。自注册节点在创建node对象时自动注册此部分内容。但是,如果是手动管理node对象的话,则也需要手动设置此部分内部。

    Kubernetes scheduler在调度pod之前,首先要确保node上有足够运行pod的资源,它要确保node上运行的所有container占用的资源不能超过节点的 capacity。但是,默认情况下在统计node的资源占用情况时,只计算由kubelete启动的容器,其它进程占用的资源不在统计之内。

    如果想明确检视非pod进程占用的资源的话,按如下模板在每个node节点上创建manifest类型的pod:

    apiVersion: v1
    kind: Pod
    metadata:
      name: resource-reserver
    spec:
      containers:
      - name: sleep-forever
        image: k8s.gcr.io/pause:0.8.0
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
    展开全文
  • 创建zookeeper节点报错KeeperErrorCode = NoNode for... 创建zookeeper 的时候,必须在父节点存在的时候 ,才能创建节点。。如果父节点不存在则不能创建节点。 类似于 必须先创建 /app1 才能创建 ...

    创建zookeeper 的时候,必须在父节点存在的时候 ,才能创建子节点。。如果父节点不存在则不能创建子节点。

    类似于 必须先创建  /app1 才能创建 /app1/p_1 .

    不能直接创建/app1/p_1, 直接创建会报错,找不到节点

     
        

     

    posted on 2019-08-28 16:31  AnyYoung 阅读( ...) 评论( ...) 编辑 收藏

    转载于:https://www.cnblogs.com/anycc/p/11424839.html

    展开全文
  • 浅谈kubernetes:master节点和node节点

    千次阅读 2019-04-30 15:36:23
    kubernetes 整个架构分为master节点...而node节点主要负责container创建,服务的代理以及其他相关应用。 Master节点 Master 组件提供的集群控制。Master 组件对集群做出全局性决策(例如:调度),以及检测和响应集群...

    kubernetes 整个架构分为master节点和node节点,其中master节点负责pod的调度,pod的replication的数量node,endpoint以及服务账户以及令牌的管理等等;而node节点主要负责container创建,服务的代理以及其他相关应用。

    Master节点


    Master 组件提供的集群控制。Master 组件对集群做出全局性决策(例如:调度),以及检测和响应集群事件(副本控制器的replicas字段不满足时,启动新的副本)。

    Master 组件可以在集群中的任何节点上运行。然而,为了简单起见,设置脚本通常会启动同一个虚拟机上所有 Master 组件,并且不会在此虚拟机上运行用户容器(高可用)

    Master节点包括:kube-apiserver,kube-control-manager,kube-schduler,etcd,相关插件应用以及底层云控制器,其中:

    1. kube-apiserver

    kube-apiserver对外暴露了Kubernetes API。它是的 Kubernetes 前端控制层。它被设计为水平扩展,即通过部署更多实例来缩放

    2. etcd数据库

    etcd主要为kubernetes的后端数据库,就与k/v方式存储,所有的k8s集群数据都存放在此处。

    3. kube-controller-manager

    kube-controller-manager运行控制器,它们是处理集群中常规任务的后台线程。逻辑上,每个控制器是一个单独的进程,但为了降低复杂性,它们都被编译成独立的可执行文件,并在单个进程中运行。这些控制器包括:

    节点控制器: 当节点移除时,负责注意和响应。
    
    副本控制器: 负责维护系统中每个副本控制器对象正确数量的 Pod。
    
    端点控制器: 填充 端点(Endpoints) 对象(即连接 Services & Pods)。
    
    服务帐户和令牌控制器: 为新的命名空间创建默认帐户和 API 访问令牌
    4. 云控制器管理器-(cloud-controller-manager)

    cloud-controller-manager是用于与底层云提供商交互的控制器。云控制器管理器可执行组件是 Kubernetes v1.6 版本中引入的 Alpha 功能。

    cloud-controller-manager仅运行云提供商特定的控制器循环。您必须在kube-controller-manager 中禁用这些控制器循环,您可以通过在启动 kube-controller-manager 时将 --cloud-provider 标志设置为external来禁用控制器循环。

    cloud-controller-manager允许云供应商代码和Kubernetes核心彼此独立发展,在以前的版本中,Kubernetes 核心代码依赖于云提供商特定的功能代码。在未来的版本中,云供应商的特定代码应由云供应商自己维护, 并与运行 K8s 的云控制器管理器相关联。具有云提供商依赖关系:

    节点控制器: 用于检查云提供商以确定节点是否在云中停止响应后被删除
    
    路由控制器: 用于在底层云基础架构中设置路由
    
    服务控制器: 用于创建,更新和删除云提供商负载平衡器
    
    数据卷控制器: 用于创建,附加和装载卷,并与云提供商进行交互以协调卷
    5. kube-scheduler

    kube-scheduler监视没有分配节点的新创建的 Pod,选择一个节点供他们运行,即pod的调度

    6. 插件(addons)

    插件是实现集群功能的 Pod 和 Service。 Pods 可以通过 Deployments,ReplicationControllers 管理。插件对象本身是受命名空间限制的,被创建于 kube-system 命名空间。Addon 管理器用于创建和维护附加资源。

    主要包括以下插件:

    1. DNS域名注册服务

    为 Kubernetes 服务提供DNS记录,Kubernetes 启动的容器自动将 DNS 服务器包含在 DNS 搜索中。

    1. dashboard用户界面

    为kubernetes集群提供一个状态概览的UI界面。

    3.容器监控

    容器资源监控将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中,并提供用于浏览这些数据的界面

    4.日志采集

    负责将容器的日志数据保存到一个集中的日志存储中,该存储能够提供搜索和浏览接口。

    node节点


    node节点组件在每个节点上运行,维护运行的 Pod 并提供 Kubernetes 运行时环境。其中包括以下组件:

    1. kubelet

    kubelet是主要的节点代理,它监测已分配给其节点的 Pod(通过 apiserver 或通过本地配置文件),提供如下功能:挂载 Pod 所需要的数据卷(Volume)。

    1.下载 Pod 的 secrets。
    
    2.通过 Docker 运行(或通过 rkt)运行 Pod 的容器。
    
    3.周期性的对容器生命周期进行探测。
    
    4.通过创建镜像Pod(Mirror Pod) 将 Pod 的状态报告回系统的其余部分。
    
    5.将节点的状态报告回系统的其余部分
    2. kube-proxy

    kube-proxy通过维护主机上的网络规则并执行连接转发,实现了Kubernetes服务代理

    3. container runtime interface

    运行容器的cri,比如:container 或者rkt

    4. supervisord

    supervisord 是一个轻量级的进程监控系统,可以用来保证 kubelet 和 docker 运行。

    5. Fluentd

    fluentd 是一个守护进程,它有助于提供集群层面日志 集群层面的日志

    全局组件


    全局组件主要指的是CNI,即容器网络,它贯穿整个kubernetes集群,不管master节点应用还是node节点应用都必须同处于一个网络,从而保证整个服务正常访问!

    以上就是整个k8s节点相关的功能介绍,具体介绍请参考kubernetes官方文档!

    转载于:https://blog.51cto.com/blief/2387377

    展开全文
  • k8s 的介绍容器化相对于传统虚拟化优势选择docker容器部署要使用k8s的原因k8s Master节点和Node节点各个节点组件间的关系Master节点组件介绍Node节点组件介绍ks8 核心概念 容器化相对于传统虚拟化优势 如果要选择k8s...
  • 问题描述: k8s集群中有一个master节点和两个node节点,其中一个node1节点能够与master节点正常通信,创建的pod也可以正常访问。但是另外一个node2节点cni0接口与其他两个节点都无法通信,创建的pod也无法访问,ping...
  • 图算法之节点分类Node Classification

    千次阅读 2020-06-01 22:35:14
    在图谱当中,有一项很重要的任务,节点分类。该任务通常是给定图中某些节点对应的类别,从而预测出生于没有标签的节点属于哪一个类别,该任务也被称为半监督节点分类。 本文主要要解决的问题就是如何做节点分类。 图...
  • Kubernetes集群分为一个Master节点和若干Node节点。 集群所有的控制命令都传递给Master组件,在Master节点上运行(kubectl命令在其他Node节点上无法执行)。 通常在Master节点启动所有的Master组件,包括etcd、api...
  • 通过kubeadm搭建kubernetes集群环境,加入node节点,部署应用进行体验
  • Kubernetes集群中部署Node节点

    万次阅读 2017-10-16 14:38:51
    Kubernetes集群中的Node节点部署kubernetes的Node节点包含如下组件: flanneld docker kubelet kube-proxy 环境变量需要的变量。$ # 替换为 kubernetes master 集群任一机器 IP $ export MASTER_IP=10.50.101.41 $ ...
  • k8s二进制集群中删除node节点,并重新加入集群一、删除node04节点1.查看当前集群的节点信息2.使用kubectl命令删除node节点3.查看当前集群的节点信息4.在node节点上彻底删除集群信息5.node节点停止kubelet服务二、node...
  • k8s集群手动添加node节点

    千次阅读 2019-08-02 09:36:26
    手动添加node节点 添加网络服务 # 从node节点拷贝相关证书 scp -r /etc/kubernetes 10.32.254.18:/etc/ # 解压 tar -xf flannel-v0.9.1-linux-amd64.tar.gz cp {flanneld,mk-docker-opts.sh} /usr/local/bin/ cp ...
  • 实际应用中发现,如果不做处理,当集群内应用数量不断增加时,会占满node节点的系统资源,导致某node节点挂掉,同时也会造成openshift集群的卡死。 解决思路为设置node节点系统资源预留值。 参考官方文档:...
  • 在淘宝上购买了相应课程的博主在一步一步按照视频讲解搭建的过程中发现有很多视频...node 节点的搭建过程,希望对大家有所帮助。 主机规划: master虚拟机一台, 2C4G, 域名:master.example.com, IP地址:192.168....
  • k8s二进制集群中添加/新增node节点

    千次阅读 2019-10-17 09:35:50
    @[TOC](k8s实践(三) 二进制集群中添加node节点) 原有环境说明 主机名 系统版本 ip地址 docker version kubelet version kubeadm version kubectl version flannel version 备注 master centos-release-7-7....
  • 创建Pod时决定Pod创建在那个node节点上则是由scheduler模块来进行调度。 目前工作中用的kubernetes版本为1.5版本,在使用过程中发现存在同名节点导致调度异常的问题,这周仔细研究了下kubernetessche...
  • k8s集群部署四:node节点组件部署

    千次阅读 2018-04-15 05:19:55
    以下操作均在node节点上进行 从master上拷贝kubeconfig文件到node节点 scp /root/ssl/*kubeconfig 10.10.99.233:/opt/kubernetes/cfg/ scp /root/ssl/*kubeconfig 10.10.99.228:/opt/kubernetes/cfg/ 下载...
  • node节点创建kubeconfig文件 以下操作在master上进行,然后统一分发到node节点上 kubeconfig是用于在node节点上kubelet和kube-proxy访问集群的认证。 下载kubectl 在master上下载kubectl wget...
  • Kubernetes及其Master/Node节点

    千次阅读 2019-01-14 23:54:46
    说明:Kubernetes集群中不存在创建Node的问题,因为作为Node的物理机或VM,是由云提供的。但是,这些外部云提供者提供的Node,需要在Kubernetes集群中声明,并通过Master上的Node Controller进行管理控制。   ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 375,610
精华内容 150,244
关键字:

创建node节点类