kube-proxy
四层与七层1、四层负载均衡(例如nginx中直接配置stream,如下)1234567891011stream { upstream k3s { least_conn; server 10.0.2.0:6443 max_fails=3 fail_timeout=5s; server 10.0.2.6:6443 max_fails=3 fail_timeout=5s; } server { listen 6443; proxy_pass k3s; }} 0、负载均衡器用 ip+port 接收请求,再直接转发到后端对应服务上 1、四层负载均衡仅能转发TCP/IP协议、UDP协议、通常用来转发端口,如:tcp/22、udp/53; 2、四层负载均衡可以用来解决七层负载均衡端口限制问题;(七层负载均衡最大使用65535个端口号) 3、四层负载均衡可以解决七层负载均衡高可用问题;(多台后端七层负载均衡能同事的使用) 4、四层的转发效率比七层的高得多,但仅支持tcp...
kubeconfig文件详解
在node节点上可以执行kubectl命令吗? 12[root@k8s-node1 ~]# kubectl get nodeThe connection to the server localhost:8080 was refused - did you specify the right host or port? localhost:8080 这个端口是k8s api(kube-apiserver非安全端口)的端口,*在master上面可以执行成功其实走的是配置文件。但是在node上连接的是本地的非安全端口。* 其实还有一个对外端口是6443,这个是kube-apiserver监听的,masterip:6443安全端口 12[root@k8s-master ~]# netstat -tpln | grep 6443tcp6 0 0 :::6443 :::* LISTEN 92617/kube-apiserve 什么叫安全端口,什么叫非安全端口 kube-apiserve...
kubeconfig文件详解
Kubectl 安装参考: https://blog.csdn.net/All_Dream_and_you/article/details/124343080 官方文档 kubectl for linux 操作系统:centos7.5命令行: bash 安装 Kubectl123456789101112131415161718#下载安装包 如果需要指定版本 使用版本号替换 $(curl -L -s https://dl.k8s.io/release/stable.txt) 即可curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"#验证可执行文件#下载校验和curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"...
kubernetes 安装 ingress nginx controller
参考:https://www.cnsre.cn/posts/210902330007 前言Service可能会有很多,如果每个资源都绑定一个 node port的话,主机则需要开放外围的端口进行服务调用,管理上会比较混乱。 比较优雅的方式是通过一个外部的负载均衡器,比如 nginx ,绑定固定的端口比如80,然后根据域名/服务名向后面的Service Ip转发,但是这里对问题在于:当有新服务加入的时候如何修改 Nginx 配置? 手动改或者 Rolling Update Nginx Pod 都是不现实的。 对于这个问题, k8s 给出的七层解决方案是:Ingress ingress-nginxingress nginx 官方网站 ingress nginx 仓库地址 ingress-nginx v1.0 最新版本 v1.0 适用于 Kubernetes 版本 v1.19+ (包括 v1.19 ) Kubernetes-v1.22+ 需要使用 ingress-nginx>=1.0,因为 networking.k8s.io/v1beta 已经移除 直接部署 ingre...
kubernetes的master节点挂了对整个集群有什么影响
如果master挂掉,已经在节点上运行起来的pod还是可以继续对外提供服务,但是诸如动态扩展,部署新的服务,pod等与调度和管理相关的工作是干不了的。 k8s集群相关的数据都存储在etcd(一些类似k3s等发行版可存储在mysql/postgre)上,master本身属于无状态服务,k8s支持多master结构来达到HA。
优雅停止(Gracful Shutdown)与 502/504 报错
优雅退出,业务侧需要做的任务是处理SIGTERM信号 如果 Pod 正在处理大量请求(比如 1000 QPS+)时,因为节点故障或「竞价节点」被回收等原因被重新调度,可能会观察到在容器被 terminate 的一段时间内出现少量 502/504。 为了搞清楚这个问题,需要先理解清楚 terminate 一个 Pod 的流程: 123451、Pod 被删除,状态置为 Terminating。kube-proxy 更新转发规则,将 Pod 从 service 的 endpoint 列表中摘除掉,新的流量不再转发到该 Pod。2、如果 Pod 配置了 preStop Hook ,将会执行。3、kubelet 对 Pod 中各个 container 发送 SIGTERM 信号以通知容器进程开始优雅停止。4、等待容器进程完全停止,如果在 terminationGracePeriodSeconds 内 (默认 30s) 还未完全停止,就发送 SIGKILL 信号强制杀死进程。5、所有容器进程终止,清理 Pod 资源。 注意:1和2 两个工作是异步发生的,所以在未设置 preSt...
最大最小内存设置为一致
在 Kubernetes 中,像 CPU 这样的资源被称作“可压缩资源”(compressible resources)。它的典型特点是,当可压缩资源不足时,Pod 只会“饥饿”,但不会退出。而像内存这样的资源,则被称作“不可压缩资源(incompressible resources)。当不可压缩资源不足时,Pod 就会因为 OOM(Out-Of-Memory)被内核杀掉。 1.容器最小内存和最大内存设置为一致简单来理解:最小内存等同于k8s的resources:requests资源,最大内存等同于resources:limits资源。参考:为容器和 Pod 分配内存资源 | Kubernetes 刚才的配置,我们查看对应yml文件可以看到,对应的memory的请求和限制保持一致。 一般情况下,对于核心资源,我们推荐 requests == limits,这个是为什么呢? 这里涉及pod的三种模式: Guaranteed 类别:当 Pod 里的每一个 Container 都同时设置了 requests 和 limits,并且 requests 和 l...
查看pod是否正常打印日志
查看pod是否正常打印日志,并发送webhook到企微 12345678910111213141516171819202122232425262728293031323334#!/bin/sh# 获取当前UTC时间utc_now=`date -u`# 将时间转换为timestamptimestamp_now=`date -d "$utc_now" +%s`PODNAME=NAMASPACE=function restart_pod() { for i in `kubectl get pod -n iot|grep $PODNAME|awk '{print $1}'`;do for time in `kubectl logs --tail=1 --timestamps $i -n $NAMASPACE | awk '{print $1}'`;do timestamp_pod=`date -d "$time" +%s` d...
根据pid查找到pod的一些信息
编辑~/.bashrc, 粘贴以下函数,并执行source ~/.bashrc使其生效, 使用的时候执行函数podinfo $pid通过pid 获取pod name12345podinfo() { CID=$(cat /proc/$1/cgroup | awk -F '/' '{print $5}') CID=$(echo ${CID:0:8}) crictl inspect -o go-template --template='{{index .status.labels "io.kubernetes.pod.name"}}' $CID} 通过pid获取pod id123podUid() { cat /proc/$1/mountinfo | grep "etc-hosts" | awk -F / {'print $6'}&...
滚动更新控制副本数
适用停机发布Recreate:设置spec.strategy.type=Recreate,表示Deployment在更新Pod时,会先杀掉所有正在运行的Pod,然后创建新的Pod。 适用零停机发布RollingUpdate:设置spec.strategy.type=RollingUpdate,表示Deployment会以滚动更新的方式来逐个更新Pod。 服务在滚动更新时,deployment控制器的目的是:给旧版本(old_rs)副本数减少至0、给新版本(new_rs)副本数量增至期望值(replicas),以下是kubernetes提供的两个参数: maxUnavailable:和期望ready的副本数比,不可用副本数最大比例(或最大值),这个值越小,越能保证服务稳定,更新越平滑; maxSurge:和期望ready的副本数比,超过期望副本数最大比例(或最大值),这个值调的越大,副本更新速度越快。 取值范围 数值(两者不能同时为0。) maxUnavailable: [0, 副本数] maxSurge: [0, 副本数] 比例(两者不能同时...
