1. 背景Kubernetes作为容器应用的管理中心，对集群内部所有容器的生命周期进行管理，结合自身的健康检查及错误恢复机制，实现了集群内部应用层的高可用性。Kubernetes服务本身的稳定运行对集群管理至关重要，影响服务稳定的因素一般来说分为两种,一种是服务本身异常或者服务所在机器宕机，另一种是因为网络问题导致的服务不可用。本文将从存储层、管理层、接入层三个方面介绍高可用Kubernetes集
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，让调度器感知节点有多少资源被分配了，以便做出合理的调度决策，让集群节点的资源能够被合理的分配使用，避免陷入资源分配不均导致一些意外发生。
1. 在所有节点上安装Docker和kubeadm 2. 部署Kubernetes Master 3. 部署容器网络插件 4. 部署 Kubernetes Node，将节点加入Kubernetes集群中 5. 部署Dashboard Web页面，可视化查看Kubernetes资源
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+
原生 kubernetes 调度器只能基于资源的 resource request 进行调度，然而 Pod 的真实资源使用率，往往与其所申请资源的 request/limit 差异很大，这直接导致了集群负载不均的问题： 1. 集群中的部分节点，资源的真实使用率远低于 resource request，却没有被调度更多的 Pod，这造成了比较大的资源浪费； 2. 而集群中的另外一些节点，其资源的真实使用率事实上已经过载，却无法为调度器所感知到，这极大可能影响到业务的稳定性。
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
