k8s

如果master挂掉，已经在节点上运行起来的pod还是可以继续对外提供服务，但是诸如动态扩展，部署新的服务，pod等与调度和管理相关的工作是干不了的。 k8s集群相关的数据都存储在etcd(一些类似k3s等发行版可存储在mysql/postgre)上，master本身属于无状态服务，k8s支持多master结构来达到HA。

优雅退出，业务侧需要做的任务是处理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 两个工作是异步发生的，所以在未设置...

Kubernetes 中的 DNS在 Kubernetes 中，服务发现有几种方式：①：基于环境变量的方式②：基于内部域名的方式 基本上，使用环境变量的方式很少，主要还是使用内部域名这种服务发现的方式。 其中，基于内部域名的方式，涉及到 Kubernetes 内部域名的解析，而 kubedns，是 Kubernetes 官方的 DNS 解析组件。从 1.11 版本开始，kubeadm 已经使用第三方的 CoreDNS 替换官方的 kubedns 作为 Kubernetes 集群的内部域名解析组件，我们的重点，是 CoreDNS，但是在开始 CoreDNS 之前，需要先了解下 kubedns Kubernetes 中的域名是如何解析的在 Kubernetes 中，比如服务 a 访问服务 b，对于同一个 Namespace下，可以直接在 pod 中，通过 curl b 来访问。对于跨 Namespace 的情况，服务名后边对应 Namespace即可。比如 curl b.default。那么，使用者这里边会有几个问题： ①：服务名是什么？②：为什么同一个 Namespace...

转自: https://cloud.tencent.com/developer/article/1495508 Kubernetes 对内存资源的限制实际上是通过 cgroup 来控制的，cgroup 是容器的一组用来控制内核如何运行进程的相关属性集合。针对内存、CPU 和各种设备都有对应的 cgroup。cgroup 是具有层级的，这意味着每个 cgroup 拥有一个它可以继承属性的父亲，往上一直直到系统启动时创建的 root cgroup。关于其背后的原理可以参考：深入理解Kubernetes资源限制：内存。 今天我们将通过实验来探索容器在什么情况下会被 oom-killed。 1. 实验准备首先你需要一个 Kubernetes 集群，然后通过 kubectl 创建一个 Pod，内存限制为 123Mi。 123$ kubectl run --restart=Never --rm -it --image=ubuntu --limits='memory=123Mi' -- shIf you don't see a command prompt,...

相关概念引自kubesphere - requests与limits 简介为了实现 K8s 集群中资源的有效调度和充分利用， K8s 采用requests和limits两种限制类型来对资源进行容器粒度的分配。每一个容器都可以独立地设定相应的requests和limits。这 2 个参数是通过每个容器 containerSpec 的 resources 字段进行设置的。一般来说，在调度的时候requests比较重要，在运行时limits比较重要。 一些本地临时存储的配置 **注: ** 当容器申请内存超过limits时会被oomkill，并根据重启策略进行重启。而cpu超过limit则是限流，但不会被kill 由于CPU资源是可压缩的，进程无论如何也不可能突破上限，因此设置起来比较容易。对于Memory这种不可压缩资源来说，它的Limit设置就是一个问题了，如果设置得小了，当进程在业务繁忙期试图请求超过Limit限制的Memory时，此进程就会被Kubernetes杀掉 1234567891011121314# requests:...

Cluster IP即Service的IP，通常在集群内部使用Service Name来访问服务，用户不需要知道该IP地址，kubedns会自动根据service name解析到服务的IP地址，将流量分发给Pod。 Service Name才是对外暴露服务的关键。在kubeapi的配置中指定该地址范围。 默认配置 12--service-cluster-ip-range=10.254.0.0/16--service-node-port-range=30000-32767 Pod IPflannel通过配置flannel的network和subnet来实现。 默认配置 12FLANNEL_NETWORK=172.30.0.0/16FLANNEL_SUBNET=172.30.46.1/24 Pod的IP地址不固定，当pod重启时IP地址会变化。 该IP地址也是用户无需关心的。 但是Flannel会在本地生成相应IP段的虚拟网卡，为了防止和集群中的其他IP地址冲突，需要规划IP段。 主机/Node...

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107#!/usr/bin/env bash# 0.定义webhook urlwebhookurl=https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=4b7128c5-0e5a-46f5-b5ef-77dff4eb5c99# 1.定义变量值,namespace不能为空if [ -z "$1" ]; then exit 1else nameSpace=$1fi# 节点cpu限制值(%)cpuVPT=85# 节点mem限制值(%)memVPT=85# pod...

方法1：滚动重启从1.15版开始，Kubernetes允许您滚动重启部署。作为Kubernetes的新增功能，这是最快的重启方法。 kubectl rollout restart deployment [deployment_name] 上面提到的命令将逐步执行关闭操作，并重新启动deployment中的每个pod容器。在重启过程中应用仍然可用，因为大多数容器仍在运行。 方法2：使用环境变量另一种方法是设置或更改环境变量，以强制Pod重新启动并与您所做的更改同步。 例如，可以更改容器部署日期： kubectl set env deployment [deployment_name] DEPLOY_DATE="$(date)" 在上面的示例中，该命令**set env设置环境变量的更改，deployment...

在 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 和...

查看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` ...