一个项目的master节点down了之后kubelet起不来，由于是远古时期的项目，早期未作任何监控手段。因此也没有监控，没有文档，非常棘手经过查看，master节点的kubelet未启动，查看kubelet日志: failed to run Kubelet: unable to load bootstrap kubeconfig: stat /etc/kubernetes/bootstrap-k

我们有两个版本的内核节点，分别是两个批次的节点，安装了3.10.95和5.4.x的内核 在出现Readiness probe failed和Liveness probe failed是一次pod驱逐而后就发生的 查看事件 # kubectl get events --sort-by='.lastTimestamp' -n kube-system LAST SEEN TYPE REASON OBJE

简单的进行初始化 1，安装相同版本的docker,复制必要的镜像文件到node节点导入2，同步时间3，将桥接的IPv4流量传递到iptables的链 cat > /etc/sysctl.d/k8s.conf << EOF net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 n

Kubernetes需要确保在 Pod 中运行的 应用是健康的。一旦应用出现问题，kubelet作为守护进程会根据为 Pod 设置的重启策略(restartPolicy)重启 Pod。现在的问题是 k8s 如何检测不健康的应用程序？答案是通过Probes。 restartPolicy默认为：Always Liveness、Readiness 和 Startup 探针 Kubernetes有 3 种

通过减少误操作带来的问题和提高服务质量，Kubernetes liveness 和 readiness 探针可用于使服务更健壮和更有弹性。但是，如果不仔细实施这些探测器，它们可能会严重降低服务的整体操作，以至于让人们觉得没有它们会更好。 在本文中，将探讨在实现 Kubernetes 的 liveness 和 readiness 探针时如何避免使服务可靠性变差。虽然本文的重点是 Kubernetes

之前，我写过一篇Kubernetes Liveness 和 Readiness 探测避免给自己挖坑续集，描述了 Kubernetes 的 liveness 和 readiness 探针如何无意中降低服务可用性，或者导致长时间的中断。 Kubernetes liveness 和 readiness 探针是旨在提高服务可靠性和可用性的工具。但是，如果不考虑整个系统的动态，尤其是异常动态，你就有可能使服

Kubernetes liveness 和 readiness 探针可用于提高服务的可靠性。但是，如果不小心使用它们，它们可能会适得其反，并通过微妙的、意想不到的后果降低服务的可靠性。 我写了一个分别有几部分的文章(见延伸阅读)，介绍如何使用 Kubernetes 的 liveness 和 readiness 探针来避免“给自己挖坑”。我详述的一些问题与启动动态有关。Kubernetes 1.16

在上次处理 kubelet.go node "master" not found问题之后的一段时间里面，我又遇到了相同的问题发生在其他节点。它的表现方式是/etc/kubernetes/bootstrap-kubelet.conf: no such file or directory 我此前也写了一篇文章linuxea:处理k8s kubelet.go node "master" not foun

我们知道kuberentes的网络在k8s中是下沉的，为了更好理解kubernetes-cni的插件在同节点的网络中的通讯情况， 我们安装ensp来模拟两层设备在网络中的使用 当发起一条ping请求的时候，将会在arp中进行广播 当收到这个ip是自己的时候回应，不是则丢弃 在两层网络中，主要用来验证如下的这两条 PC配置ip 选中所有启动 双击交换机你可以看到启动的页面，模拟的真实交换机的 此时m

网络报文在传输中，必然是需要知道通讯四元组，缺一不可，因此在不知道的情况下会发送arp广播来寻找，当寻找到之后就能获取到了四元组的信息，而后开始发送。 现在有一个问题，当A发起请求，到达B，MAC地址会变吗？相信这是一个简单的问题，那么很有可能你并不是在意 答案是：网络ip地址没有发生变化，而mac地址在一直发生变化 ensp模拟一下这个环境，拓扑如下 我们利用路由器来做，分别配置不同的lo接口来

ip地址 IP地址是在计算机网络中被用来唯一标识一台设备的一组数字。IPv4地址由32位二进制数值组成，但为了便于用户识别和记忆，采用了“点分十进制表示法”。采用了这种表示法的IPv4地址由4个点分十进制整数来表示，每个十进制整数对应一个字节。IPv4地址由如下两部分组成： 网络号码字段（Net-id）：用来标识一个网络。 主机号码字段（Host-id）：用来区分一个网络内的不同主机。对于网络号相

有这么一个场景，前面是一个中国移动的云服务器，他们的网络环境是通过SNAT和DNAT的方式进行做的网络转换。这种情况在云环境中并不多见，一般发生在自建物理机房中，通常而言，DNAT和SNAT发生在防火墙或者外部路由阶段。 一个IP地址和不同的端口来进行映射到后端的一个节点上的某个端口上，这种情况下走的必然是4层转发，这就有出现了一个问题，你的https是无法在这里进行卸载的，要么在前端架设代理层，

应用程序并不总是在稳定状态下运行。会根据日期、时间或特定事件而波动。CPU 需求各不相同，运行时内存和网络需求也各不相同。而应用程序不断变化的需求，由Kubernetes来调度程序分配计算或内存资源，这些可能会导致Kubernetes上的node或者pod处于不可用状态的原因之一，而这些pod最终是关联到应用程序上，只有将这些资源被分配给其他应用程序或暂停，直到一切结束。 这种重新分配可能有意或意

网卡 网卡分为很多类型，虚拟网卡，物理网卡等。 物理网卡 物理网卡需要通过网卡驱动在内核中注册后才能工作，它在内核网络协议栈和外界网络之间传递数据，用户可以为物理网卡配置网卡接口属性，比如IP地址，这些属性都配置在内核的网络协议栈中。内核也可以直接创建虚拟的网卡，只要为虚拟网卡提供网卡驱动程序，使其在内核中可以注册成为网卡设备，它就可以工作。 从Linux内核3.x版本开始，物理网卡和虚拟网卡是平

有些朋友问怎么在windows上调试自己的环境，刚好最近也在自己的虚拟环境调试，就整理下了文档 以kubectl和helm以及kustomize为例 下载对应的包 你要正常使用当你包，必须是与你kubernetes版本匹配的，这些信息在他们的readme.md中都有介绍 假如你的k8s 是1.20的，那你就不能使用与此版本差距太大的版本以免出现未知的问题 而其他的大版本的包使用方式一直在发送变化

首先需要已经配置好了一个ingress-nginx亦或者使用ACK上的ingress-nginx鉴于对ingress-nginx的状态，或者流量的监控是有一定的必要性，配置监控的指标有助于了解更多细节 通过使用kube-prometheus的项目来监控ingress-nginx，首先需要在nginx-ingress-controller的yaml中配置10254的端口，并且配置一个service，

ingress-nginx的官网提供了更多的一些配置信息，包括url重写，金丝雀，尽管金丝雀支持并不完美，ingress-nginx仍然是最受欢迎的ingress之一。在上一篇中，我介绍了ingress-nginx应用常见的两种方式,并且采用的最新的版本，早期有非常陈旧的版本在使用。鉴于此，随后打算将ingress-nginx重新理一遍，于是就有了这篇，后续可能还会有 ingress-nginx本

无论是debian还是redhat，亦或者其他linux发行版，都有一个包管理用来解决依赖问题，而在kubernetes中，helm是用来管理kubernetes应用程序，其中charts是可以定义一个可以进行安装升级的应用程序，同时也容易创建起来，并且进行版本管理。而在越复杂的应用程序来讲，helm可以作为一个开箱即用的，单单从使用角度来看，类似于yum或者apt的，使用起来，会更加流行。 比如

ingress-nginx basic auth认证是最简单和基础的，要使用它，需要安装httpd，提供一个htpasswd，而后使用htpasswd -c auth NAME 的方式创建一个文件，而后是以哦那个create来创建，如下 kubectl create secret generic bauth --from-file=NAME 这通常能解决使用，但是需要额外安装一个软件包，或许需要另

helm说白了其实就是一个模板渲染系统，核心就在templates和values，模板使用了go template编写的，并且增加了sprig库，共计50个左右的附加模板函数和其他的一些函数。如果要进行使用，必然要遵循template的模板的约定)，比如 {{ if pipeline }} T1 {{ else }} {{ if pipeline }} T0 {{end}} { end} {{ r