1. 背景Kubernetes作为容器应用的管理中心,对集群内部所有容器的生命周期进行管理,结合自身的健康检查及错误恢复机制,实现了集群内部应用层的高可用性。Kubernetes服务本身的稳定运行对集群管理至关重要,影响服务稳定的因素一般来说分为两种,一种是服务本身异常或者服务所在机器宕机,另一种是因为网络问题导致的服务不可用。本文将从存储层、管理层、接入层三个方面介绍高可用Kubernetes集
# k8s node 节点notereday , 节点日志一直报节点没有找到 当Kubernetes集群中的节点(node)状态显示为NotReady时,可能是由于各种原因导致的。其中一种可能的原因是节点无法被Kubernetes控制平面(control plane)找到。下面是一些可能的排查步骤:
K8S ETCD server_proposals失败数大于10
helm 部署项目地址Releases · helm/helm (github.com)安装流程[root@k8s-master2 ~]# mkdir helm[root@k8s-master2 ~]# cd helmtar zxvf helm-v3.5.4-linux-amd64.tar.gz cp -av linux-amd64//helm /usr/local/bin/helm h
项目地址prometheus-operator/kube-prometheus: Use Prometheus to monitor Kubernetes and applications running on Kubernetes (github.com)1. 初识prometheus1.1 prometheus简介Prometheus is an open-source systems
Ingress 是什么?项目地址:https://github.com/kubernetes/ingress-nginxIngress 公开从集群外部到集群内服务的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。下面是一个将所有流量都发送到同一 Service 的简单 Ingress 示例:图. Ingress 
kubeadm是官方提供的开源工具,是一个开源项目,用于快速搭建kubernetes集群,目前是比较方便和推荐使用的。kubeadm init 以及 kubeadm join 这两个命令可以快速创建 kubernetes 集群。Kubeadm初始化k8s,所有的组件都是以pod形式运行的,具备故障自恢复能力。 kubeadm是工具,可以快速搭建集群,也就是相当于用程序脚本帮我们装好了集群,属于自动部署,简化部署操作,自动部署屏蔽了很多细节,使得对各个模块感知很少,如果对k8s架构组件理解不深的话,遇到问题比较难排查。 kubeadm适合需要经常部署k8s,或者对自动化要求比较高的场景下使用。 二进制:在官网下载相关组件的二进制包,如果手动安装,对kubernetes理解也会更全面。 Kubeadm和二进制都适合生产环境,在生产环境运行都很稳定,具体如何选择,可以根据实际项目进行评估。
问题1:ipvs是什么?ipvs (IP Virtual Server) 实现了传输层负载均衡,也就是我们常说的4层LAN交换,作为 Linux 内核的一部分。ipvs运行在主机上,在真实服务器集群前充当负载均衡器。ipvs可以将基于TCP和UDP的服务请求转发到真实服务器上,并使真实服务器的服务在单个 IP 地址上显示为虚拟服务。 问题2:ipvs和iptable对比分析kube-pr
calico 固定IP地址背景之前被开发问过 , 他们通信使用pod ip 通信 ,pod 重启 地址 改变!!那我就固定 pod ip前提条件集群中使用 calico可以参考我上一篇文章,如下Kubernetes网络模型 -flannel +Calico上干货添加如下字段可以cni.projectcalico.org/ipAddrs: "[\"10.244.1.100\"]"
实际上,Calico项目提供的网络解决方案,与Flannel的host-gw模式几乎一样。也就是说,Calico也是基于路由表实现容器数据包转发,但不同于Flannel使用flanneld进程来维护路由信息的做法,而Calico项目使用BGP协议来自动维护整个集群的路由信息。 BGP英文全称是Border Gateway Protocol,即边界网关协议,它是一种自治系统间的动态路由发现协议,与其他 BGP 系统交换网络可达信息。
备份所有命名空间#!/bin/shfor ns in $(kubectl get ns | awk '{print $1}'|grep -v NAME);doresult_get=$(kubectl get -o=name pvc,configmap,serviceaccount,secret,ingress,service,deployment,statefulset,hpa,job,cron
背景工具介绍nsenter 是一款可以进入进程的名称空间中。例如,如果一个容器以非 root 用户身份运行,而使用 docker exec 进入其中后,但该容器没有安装 sudo 或未 netstat ,并且您想查看其当前的网络属性,如开放端口,这种场景下将如何做到这一点?nsenter 就是用来解决
CoreDNS 作为 Kubernetes 集群的域名解析组件,如果性能不够可能会影响业务,本文介绍几种 CoreDNS 的性能优化手段。合理控制 CoreDNS 副本数根据集群规模预估 coredns 需要的副本数,直接调整 coredns deployment 的副本数:查看当前集群pod 数量kubectl -n kube-system scale --replicas=3 deployme
将 Pod 打散调度到不同地方,可避免因软硬件故障、光纤故障、断电或自然灾害等因素导致服务不可用,以实现服务的高可用部署。Kubernetes 支持两种方式将 Pod 打散调度:Pod 反亲和 (Pod Anti-Affinity)Pod 拓扑分布约束 (Pod Topology Spread Constraints)本文介绍两种方式的用法示例与对比总结。使用 podAntiAffinity将 P
request 的值并不是指给容器实际分配的资源大小,它仅仅是给调度器看的,调度器会 "观察" 每个节点可以用于分配的资源有多少,也知道每个节点已经被分配了多少资源。被分配资源的大小就是节点上所有 Pod 中定义的容器 request 之和,它可以计算出节点剩余多少资源可以被分配(可分配资源减去已分配的 request 之和)。如果发现节点剩余可分配资源大小比当前要被调度的 Pod 的 reuqest 还小,那么就不会考虑调度到这个节点,反之,才可能调度。所以,如果不配置 request,那么调度器就不能知道节点大概被分配了多少资源出去,调度器得不到准确信息,也就无法做出合理的调度决策,很容易造成调度不合理,有些节点可能很闲,而有些节点可能很忙,甚至 NotReady。 所以,建议是给所有容器都设置 request,让调度器感知节点有多少资源被分配了,以便做出合理的调度决策,让集群节点的资源能够被合理的分配使用,避免陷入资源分配不均导致一些意外发生。
清理非running 的podkubectl get pod -o wide --all-namespaces | awk '{if($4!="Running"){cmd="kubectl -n "$1" delete pod "$2; system(cmd)}}'清理非Evicted 的podkubectl get pod -o wide --all-namespaces | awk '{if(
kubectl是陈述式资源管理方法,用于与apiservice进行通信,将用户在命令行输入的命令转化为apiservice能识别的信息,进而实现管理k8s各种资源的一种有效途径。 k8s中文社区学习文档:http://docs.kubernetes.org.cn/ https://kubernetes.io/zh/docs/concepts/arch
1. 在所有节点上安装Docker和kubeadm 2. 部署Kubernetes Master 3. 部署容器网络插件 4. 部署 Kubernetes Node,将节点加入Kubernetes集群中 5. 部署Dashboard Web页面,可视化查看Kubernetes资源
1、设置节点不可调度kubectlcordon node02设置node02不可调度,查看各节点状态,发现node02为SchedulingDisabled,此时master不会将新的pod调度到该节点上,但是node02上pod还是正常运行。2、驱逐节点上的podkubectl drainnode02 --delete-local-data --ignore-daemonsets --force
K8s问题一 服务获取pod ip (个人认为) 不合理,集群内部推荐使用cluster ip 集群外部使用问题二K8s 调度不合理问题排查方案一修改matser ,node节点 最大pod 数量 (需要评估总共pod 数量,以及各节点需要分配的pod 数量)以达到 均衡的目的以下为本地实验案例没问题可以先上测试修改master 节点数 数(多master 都需要修改)1、sys
#! /bin/bash#对实际使用内存大于75%的机器停止调度,对实际使用内存小于65%的 关闭调度# 获取实际内存小于或等于65%的机器memory_lt_65=`kubectl top nodes |awk '{if($5+0<=65) print $1}'`# 获取实际内存大于或等于75%的机器memory_gt_75=`kubectl top nodes |awk '{if($5+
恢复Master节点注意:本教程只适用于k8s-1.17.x的版本,不适用于k8s-1.8.x的版本有时候,K8S的某个Master节点因为故障(比如系统盘或数据盘坏掉了)导致重装了操作系统,但是此时该节点还在K8S集群和数据库中,但是为异常状态。本节,主要针对这种情况介绍如何恢复这个Master节点。现状假设有三个Master节点:20,21,22;22主机的系统盘被重装了操作系统,起来后节点
原生 kubernetes 调度器只能基于资源的 resource request 进行调度,然而 Pod 的真实资源使用率,往往与其所申请资源的 request/limit 差异很大,这直接导致了集群负载不均的问题: 1. 集群中的部分节点,资源的真实使用率远低于 resource request,却没有被调度更多的 Pod,这造成了比较大的资源浪费; 2. 而集群中的另外一些节点,其资源的真实使用率事实上已经过载,却无法为调度器所感知到,这极大可能影响到业务的稳定性。
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号