在上次处理 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

通常，无状态的应用多数情况下以deployment控制器下运行，在deployment更新中，当配置清单发生变化后，应用这些新的配置。 我们假设一些都ok，也成功拉取镜像，并且以默认的25%进行滚动更新，直到更新完成。 kubectl apply -f test1.yaml 然而这一切按照预期进行，没有任何问题。 kubectl只是将配置推送到k8s后，只要配置清单没有语法或者冲突问题，返回的是0

在开发一个chart的时候就需要对整个模板进行了解，从使用角度来说，是简单的。但是去开发的时候就需要一定的认识才能够完成一个模板的开发。 而在其中用的较多的就是内置的一些函数，或者说是对象，通常，在helm的模板变量中，以大写开头的都是系统提供的，这由Go的函数约定。 内置对象 release release：release是作为顶级对象的，与下面的其他不同的是她是内置函数。字面上release是

8.9.0是skywalking发布的最后一个功能版本，从2018年开始，skywalking一直是在服务，端点，实例间依赖的关系和拓扑结构，基于代理跟踪监控发展到全栈，包括日志，跟踪，指标和事件等。也添加了更多，如vm，k8s监控，服务网格。同时也引入了更多的方式来观测，如：ebpf 但是在8.x的版本中使用了组的概念来解决混合的问题，但在v9核心中最重要的概念是LAYER 层代表计算机科学中的

在helm中除了此前的那些内置函数和定义的一些valumes的值替换，这些对象和控制语句，还有一些管道之外，仍然提供了变量。 大多数编程语言中，都有变量。如，在golang中以及groovy中都提到了全局变量和局部变量。 他们的作用域范围不同 全局变量 全局变量，顾名思义，所有都可以使用 局部变量 在某一块的代码内被使用，而代码块作用域外无法使用 有了这些的支撑，更好理解变量的出现以及使用的问题

如下图所示 我们先查看下pod的调度情况，分别是10.11.1.45和10.11.0.10在不同的两个节点，并且是不同的网段 不同的网段，那么久需要查找路由表，看路由信息 [root@master1 ~]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE marksugar-deployment-578cdd567b-9

kustomize一直是备受欢迎的yaml配置管理之一，在过去kustomize一直在解决 “提供一种操作配置数据的方法，而不会使原始配置无法被 Kubernetes 使用。”，我们不用去和其他工具做比较，因为这就是kustomize的魅力所在。 但是kustomize也有自己的缺点，它无法像helm那样灵活多变，比如，在配置多个一个Ingress的域名的时候，这在helm中将会非常简单，但是在k

在早先，容器仓库有Portus和harbor最为瞩目，harbor是vmware的产品，而前者则是由suse团队维护，但在2019portus提供了最后一个版本。但随着时间的推移，harbor提供了更多与时俱进的功能服务，这也导致harbor愈发的收到关注和使用。并且harbor是由vmware中国区成员参与，众所周知，一款提供中文界面且有优秀的产品，往往都是更受欢迎的。 harbor不仅可以存放