1.在master查看node状态 [root@master1 ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION master1 Ready control-plane,master 17h v1.20.4 node1 NotReady <none> 17h v1.20.4 2.新手新装发现问题是node节点没有安装docker  真是坑啊 装一下 yum install docker 3.再去nodes状态 ok了 [root@maste

我把三台虚拟机重启,发现2个节点一直处于NotReady状态,便去查找问题,到最后是因为子节点的kubelet的状态异常了,restart一下就好了,下面转一下解决的思路 昨天晚上,针对K8S环境做了一次压测,50路并发实施,早上起来看监控,发现昨晚8点之后,系统好像都宕掉了,一看master节点和一个node节点状态变成了not ready,主要定位手段如下: 1. 查看master kubelet状态 systemctl status kubelet 状态正常 2. 查看master kub

1.在k8smaster 服务器检查节点状态 kubectl describe nodes  aaaa #没有报错,异常信息   2.在节点上检查kubelet服务状态 netstat -tlanp|grep 6443 #正常连接到lk8s master 服务器   3.检查节点kubelet日志 journalctl -u kubelet >> kubelet.log    发现线索: 15 Dec 08 17:31:24 prd-swakopuranium-dmcu01 kubelet[1

开发部署pod的时候在wayne平台上部署不上去,删除也删除不了 先删除 kubectl delete pod pod-name --grace-period=0 --force 删除之后然后部署新的pod一直的状态在ContainerCreating 看日志kubectl describe pod 也是显示正常 看集群node状态kubectl get node,一会Noready一会ready 看kubectl日志 journalctl -xu kubelet提示都有报PLEG is not

简介 Node是Pod真正运行的主机,可以是物理机也可以是虚拟机. Node本质上不是Kubernetes来创建的, Kubernetes只是管理Node上的资源. 为了管理Pod,每个Node节点上至少需要运行container runtime(Docker).kubelet和kube-proxy服务. node基本操作:kubectl get nodes,查询所有node 从k8s移除node节点 获取节点列表:kubectl get node 确认需要移除的节点上面没有部署我们所需要的资源

节点健康检测 意义 在K8S集群运行的过程中,节点常常会因为运行时组件的问题.内核死锁.资源不足等各种各样的原因不可用.Kubelet默认对节点的PIDPressure.MemoryPressure.DiskPressure等资源状态进行了监控,但是当Kubelet上报这些状态的时候,节点很可能已经长时间处于不可用状态了,并且Kubelet可能已经开始了驱逐Pod的操作.所以原生K8S对节点健康的检测机制在一些场景下是不完善的,我们需要能够在节点出现问题之前提前发现,并且需要更加细致化的指标来描

Kubernetes 1.19.3 OS: CentOS 7.9.2009 Kernel: 5.4.94-1.el7.elrepo.x86_64 Docker: 20.10.6 先说结论,runc v1.0.0-rc93 有 bug,会导致 docker hang 住. 发现问题 线上告警提示集群中存在 2-3 个 K8s 节点处于 NotReady 的状态,并且 NotReady 状态一直持续. kubectl describe node,有 NotReady 相关事件. 登录问题机器后,查看

一,文章简述 大家好,本篇是个人的第 2 篇文章.是关于在之前项目中,k8s 线上集群中 Node 节点状态变成 NotReady 状态,导致整个 Node 节点中容器停止服务后的问题排查. 文章中所描述的是本人在项目中线上环境实际解决的,那除了如何解决该问题,更重要的是如何去排查这个问题的起因. 关于 Node 节点不可用的 NotReady 状态,当时也是花了挺久的时间去排查的. 二,Pod 状态 在分析 NotReady 状态之前,我们首先需要了解在 k8s 中 Pod 的状态都有哪些.并

在master 执行1, 不可调度 kubectl cordon k8s-node- kubectl uncordon k8s-node- #取消 2,驱逐已经运行的业务容器 kubectl drain --ignore-daemonsets --delete-local-data k8s-node- 3,如果想删除node 节点,则进行这个步骤 kubectl delete node k8s-node-

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 kind: Deployment metadata: name: villa-api labels: app: villa spec: selector: matchLabels: app: villa tier: frontend strategy: type: Recreate template: metadata: labels: app: villa tier

4.7.集群调度 4.7.1.说明 简介 Scheduler 是 kubernetes 的调度器,主要的任务是把定义的 pod 分配到集群的节点上.听起来非常简单,但有很多要考虑的问题: 公平:如何保证每个节点都能被分配资源 资源高效利用:集群所有资源最大化被使用 效率:调度的性能要好,能够尽快地对大批量的 pod 完成调度工作 灵活:允许用户根据自己的需求控制调度的逻辑 Sheduler 是作为单独的程序运行的,启动之后会一直持续链接API Server,获取PodSpec.NodeName为

首先是按照二进制方式安装的k8s. [root@ht22 calico]# cat /etc/redhat-release CentOS Linux release 7.9.2009 (Core) [root@ht22 calico]# uname -r 3.10.0-1160.45.1.el7.x

一.简介 Node是Pod真正运行的主机,可以是物理机也可以是虚拟机. Node本质上不是Kubernetes来创建的, Kubernetes只是管理Node上的资源. 为了管理Pod,每个Node节点上至少需要运行container runtime(Docker).kubelet和kube-proxy服务. node基本操作:kubectl get nodes,查询所有node 二.k8s上新增node节点 新增节点   三.移除节点 1.获取节点列表:kubectl get node  2.

错误现象 runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized 解决方式 仅就今天遇到的情况给出解决方法,基于v1.21.1版本,已安装weave,发现仍有以上错误. 我发现 /opt/cni/bin 目录下缺少很多可执行文件,处理方式是重新安装kubernete

说下背景: 上周六机房进行搬迁,我所在的网段的机器都重启了一遍.重启之后kubernetes集群不正常.如下 排查过程: # 查看节点信息 kubectl describe nodes cbov10-sso55- 时间正好是上周五搬迁的时间点,20190809,kubelet停止发布节点状态 # 查看kubelet状态 systemctl status kubelet.service 这时候看出,报错名之k8s-master,但是我们kubernetes集群的node名字是cbov10-sso5

一.k8s pod 在节点间调度控制 k8s起pod时,会通过调度器scheduler选择某个节点完成调度,选择在某个节点上完成pod创建.当需要在指定pod运行在某个节点上时,可以通过以下几种方式: 1. 在部署pod的yaml中,指定nodeName 指定了nodeName的Pod会直接跳过Scheduler的调度逻辑,直接写入PodList列表,该匹配规则是强制匹配.eg:apiVersion: extensions/v1beta1kind: Deploymentmetadata: nam

Kubernetes K8S之固定节点nodeName和nodeSelector调度详解与示例 主机配置规划 服务器名称(hostname) 系统版本 配置 内网IP 外网IP(模拟) k8s-master CentOS7.7 2C/4G/20G 172.16.1.110 10.0.0.110 k8s-node01 CentOS7.7 2C/4G/20G 172.16.1.111 10.0.0.111 k8s-node02 CentOS7.7 2C/4G/20G 172.16.1.112 10.

k8s之list-watch机制.节点调度以及亲和性 目录 k8s之list-watch机制.节点调度以及亲和性 一.list-watch机制 1. list-watch介绍 2. list-watch工作流程 二.节点调度 1. 调度策略 2. 预算策略 3. 优选策略 4. 指定调度节点 4.1 方法一:nodeName 4.2 方法二:nodeSelector 三.亲和性 1. 官方文档 2. 节点亲和性 3. Pod亲和性 4. 键值运算关系 5. 节点亲和性(硬策略)测试 5. 节点亲

一.概述 k8s暴露服务的方式有很多使用ingress.nodeport等,这类比较适用于无状态的服务,对于statefulset部署的有状态的服务,(关于statefulset的介绍参考kubernetes的官网或参考我的https://www.cnblogs.com/cuishuai/p/10243291.html),由于statefulset使用的是headless service.是固定网络标示的,也就是服务的完整域名是不会改变的.但是有两个问题: 1.物理机在k8s集群的外面没办法解析

前言 本篇部署教程将讲述k8s集群的节点(master和工作节点)部署,请先按照上一篇教程完成节点的准备.本篇教程中的操作全部使用脚本完成,并且对于某些情况(比如镜像拉取问题)还提供了多种解决方案.不过基于部署环境和k8s的复杂性,我们需要对k8s集群部署过程中的一些步骤都有所了解,尤其是“kubeadm init”命令. 目录 主节点部署  Kubeadm以及相关工具包的安装 批量拉取k8s相关镜像 使用“kubeadm init”启动k8s主节点 启动k8s主节点 kubectl认证 安装f