kubectl describe pods ****** --namespace=****** 现象 Host Port: /TCP State: Waiting Reason: CrashLoopBackOff Last State: Terminated Reason: OOMKilled 解决 resources: limits: cpu: memory: 1024Mi (扩大了内存,由512--->1024)

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

错误现象 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

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

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

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

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

首先是按照二进制方式安装的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.

开发部署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

在公司,使用dns切换,可能会比keepalived+haproxy,更精简的易维护. 毕竟,高可用只是偶尔切换,不是时时切换. 且dns解析在自己可控时,更不会影响k8s线上使用了. (部分代码,由于担心太冗长,已使用xxx代替,这些xxx完全可以自己生成的) 使用步骤如下: 先在每个master上安装etcd,运行如下命令: sh k8s.sh k8s.xxx.com.cn etcd 等每个master上的etcd安装好之后,运行如下命令: sh k8s.sh k8s.xxx.com.cn

apiserver的部署 api-server的部署脚本 [root@mast-1 k8s]# cat apiserver.sh #!/bin/bash MASTER_ADDRESS=$1 主节点IP ETCD_SERVERS=$2 etcd地址 cat <<EOF >/opt/kubernetes/cfg/kube-apiserver KUBE_APISERVER_OPTS="--logtostderr=true \\ --v=4 \\ --etcd-servers=${ET

之前的docker和etcd已经部署好了,现在node节点要部署二个服务:kubelet.kube-proxy. 部署kubelet(Master 节点操作) 1.二进制包准备 [root@k8s-master bin]# cd /usr/local/src/kubernetes/server/bin/ [root@k8s-master bin]# cp kubelet kube-proxy /opt/kubernetes/bin/ [root@k8s-master bin]# scp kube

Master节点要部署三个服务:API Server.Scheduler.Controller Manager. apiserver提供集群管理的REST API接口,包括认证授权.数据校验以 及集群状态变更等 只有API Server才直接操作etcd 其他模块通过API Server查询或修改数据 提供其他模块之间的数据交互和通信的枢纽 scheduler负责分配调度Pod到集群内的node节点    监听kube-apiserver,查询还未分配Node的Pod 根据调度策略为这些Pod分

准备说明: 因为为纯手动搭建,所以针对安装时需要的一些安装包需提前下载好 cfssl_linux-amd64. cfssljson_linux-amd64. cfssl-certinfo_linux-amd64. etcd-v3.3.10-linux-amd64.tar.gz. flannel-v0.11.0-linux-amd64.tar.gz. kubernetes-server-linux-amd64.tar.gz(网络环境原因可以上github上下载或者找台vps下载好然后再从vps上拉

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

一. k8s节点部署 1. 环境规划 系统环境概述 系统环境说明 操作系统 Ubuntu16.04 or CentOS7 选的是CentOS7        -        Kubernetes版本 v1.14.3 -        -        Docker版本 19.03.1 yum安装        -        组件服务TLS证书对应关系表 集群部署-自签TLS证书 组件 使用的证书        -        etcd ca.pem, server.pem,server-

欢迎来到 GreatSQL社区分享的MySQL技术文章,如有疑问或想学习的内容,可以在下方评论区留言,看到后会进行解答 在MGR测试中,人为制造磁盘满问题后,节点被oom killed 问题描述 在对MySQL 8.0.26 vs GreatSQL 8.0.25的对比测试过程中,有一个环节是人为制造磁盘满的场景,看看MGR是否还能正常响应请求. 在实测过程中,最后发现磁盘满的那个节点,持续时间足够久后,会因为内存消耗过大而最终被OS给OOM Kill. 这个问题我已报告BUG(#104979),

前言 正常维护工作节点的流程 当我们要进行 K8S 节点维护时往往需要执行 kubectl drain, 等待节点上的 Pod 被驱逐后再进行维护动作. 命令行如下: kubectl drain NODE 待节点排空后再进行维护操作, 内核升级等. 存在问题吗? drain 命令有一个问题, 他不会考虑资源所定义的 UpdateStrategy, 而直接强制驱逐或删除 Pod, 这样就会导致 Deployment 或 StatefulSet 资源的 Pod 达不到所设置的策略数. 思考一个案例

1.kubelet参数解析:https://blog.csdn.net/qq_34857250/article/details/84995381 2.如何在github中查找k8s代码关键字? 现在我想查找k8s源码中,关于kubelet参数pod-eviction-timeout的默认值是多少 https://github.com/kubernetes/kubernetes 先进入github对应的repository中,再Search关键字 3.计算节点频繁发生OOM,linux中发生oom

3.kubernetes安装 3.1.规划 hostname ip 内存 核 硬 说明 harbor 192.168.136.30 2G 2 100G 私有仓库 koolshare 2G 2 20G 软路由 k8s-master 192.168.136.10 2G 4 100G k8s-node1 192.168.136.20 4G 4 100G k8s-node2 192.168.136.21 4G 4 100G 安装参考视频:https://www.bilibili.com/video/av