runzhliu大数据/容器日记

Flannel 的安装逻辑如下，通过安装的 yaml 文件里有两个 initContainer，专门就是用来做 CNI 和 Flannel 配置的安装，所以命名也是叫 install-cni-plugin 以及 install-cni。的日志已经说的非常明白了，这里调整的路由是将某个节点的 ip 作为某个子网的网关，因此数据包不需要封包，就可以直接路由到这个节点上，另外就是由于。是不需要的，因为容器的网络栈只会让容器的数据包发到 cni0 这个设备上，至于后面是走。, 在同样的机器上进行测试，实测结果。..

使用过 kubeadm 来创建集群的老铁应该知道，像 kube-apiserver, kube-controller-manager, kube-scheduler 这些组件是通过静态 Pod，也就是 Static Pod 来启动的，那么也许我们会好奇，这些镜像是怎么下载的，不妨看下 kubeadm 的代码分析一下如果按常理想用 或者 看不到的话，可以换通过 和 是可以看到的拉取镜像逻辑下面的代码是 Kubernetes 1.21.7 的代码，这个版本还是 Dockershim 保留的版本，如果

上节提到执行 之后，会在机器上启动 ，实际上在 controlplane 节点上还会启动像 kube-apiserver, kube-controller-manager, kube-scheduler 甚至还有 etcd，那么这些进程又是怎么被启动的呢，下文会做简单的分析关于 Static Pod 是怎么启动的，这里需要复习一下 Static Pod 的相关内容，简而言之，默认情况下放在 目录下的文件都会被当成 Static Pod，被 kubelet 启动，而上述提到的这些组件的 manifest

不管是在 control plane 节点还是在普通的 worker 节点，kubelet 是必须要启动的进程，而 kubelet 的安装方式可以用 rpm 包也可以用二进制关于 里关于 kubelet 启动的日志，复习一下默认的配置对于默认配置，我们可以不用每个参数都非常了解，可以有需要的时候再去查相关的文档和代码drop in配置kubelet 有一些特殊的配置文件需要注意一下，不明白的可以查看官方文档在不用那些包管理器的情况下，徒手装的文档可以参考这里kubelet 真正被启动的逻辑在下面的

我们知道 的过程中会进行很多 preflight 的检查，这些主要是指内核参数、模块、CRI 等环境的检查，如果有哪些配置不符合 Kubernetes 的要求，就会抛出 Warning 或者 Error 的信息，下面就是 preflight 的主要逻辑如果有 diy 的 check 需求，可以在代码里继承这个接口进行扩展，下面举个 check 的例子，很明显 是对 CRI 也就是容器运行时进行的检查而真正起到检查的作用是下面这个函数，其实就是宿主机执行一下 ，并且接收其返回，老铁们不妨在宿主机上直接

Kubernetes 1.24 是正式弃用Dockershim 的版本，本文主要描述一下安装 Kubernetes 1.24 + containerd 1.6.6 作为 CRI 的集群，主要是采用包管理器的方式来安装，安装的流程也可以参考官方文档在 1.24 的版本，安装的时候可能会遇到这个奇怪的问题, 把这俩参数关掉就好机器初始化的配置如果是公有云的，这些配置可能会跟公有云本身的机器和系统初始化自带的一些软件和镜像有关，所以下面这些命令并不一定100%全，当然，如果缺什么软件或者配置的话，后面执

腾讯云的轻量服务器，安装了 Centos 8 Stream 系统，查看内核版本太低了点，因为最近研究 和 ，所以内核必须在 5.2 以上，所以需要手动操作一下重启机器，再次检查，内核已经更新到最新版了

随着 kubernetes 1.24 的 Release，dockershim 是正式被弃用了，这就意味着未来我们大概率是离开 Docker 越来越远的，本文只要描述一下只想在机器上安装 containerd 而不想安装 docker 相关的软件的过程下面是用 Docker 的源来安装 containerd，没错，Docker 有给官方的源来安装 containerd，因为本身 Docker 也用了 containerd，但是这个源并非 containerd 项目自身提供的安装过程上述过程只安装了 co

原生的 etcd-keeper 需要 etcd 开 auth 模式，但是 k8s 的 etcd 如果开启了 auth 是有可能有问题的（亲测有问题），为了观察 etcd 的 kv 所以小改了一下这个项目，增加了一个 的参数，可以允许 etcd-keeper 通过 tls 的模式连接 k8s 的 etcd 集群。Refer:效果如下:...

Overview项目地址在 https://github.com/runzhliu/yum-with-browser目的是解决在k8s集群里一些yum源的问题。为什么会有这个问题呢，因为通常来说k8s集群都只有集群网络，并不能直接通Internet，甚至是公司的LAN都不一定能通。所以有些同学在使用k8s部署应用的时候，尤其是把k8s当成虚拟机来用的同学，会觉得装软件很麻烦，因为通常的流程可能是只能在Dockerfile里就把需要安装的软件安装好，比如vim,curl之类的。这个项目没有什么代码，

一些特殊的工作负载，需要提前在集群母机上部署一些软件，比如一些特殊的存储或者是网络插件等，如果不考虑 k8s 的方式，一般的操作可能是通过 ssh 命令，对远程主机执行 yum install 之类的操作。在测试 Longhorn 的时候，看到 Longhorn 的文档 有提供一个 DaemonSet 来完成 iSCSI 的配置。但是 DaemonSet 有个问题就是容器会不断重启，所以个人更期望是通过一个 Job 来完成这样的操作，所以大概改造成下面的例子的样子。原理其实也不是太复杂，在特权容器内，通

Overview业务在机器学习的 GPU 集群访问集群外部域名的算法模型报超时原因分析查看了 coredns 的监控和日志，均没有发现异常，通过 ping harbor.fql.com 分析回包非常慢，而且频繁超时，于是抓包，发现 harbor.fql.com 添加了 search 域，因为本身域名只有三位，k8s 的 DNS 的 ndots 默认是5位，所以肯定会添加 search 域去解析域名的默认配置下的 Pod，ndots 为 5解决方案由业务容器通过 Pod 的 dnsConfig 自

一般场景下，容器网络都只有局域网内，无法跟 Internet 交互，如果这时候想安装一下命令的时候，简单地通过系统的 apt-get install 或者 yum install 是无法下载到公网的依赖的，除非使用局域网内的源地址，但是所有的这些都不方便呢？唯一方面就是允许用户在本地通过 kubectl 进入 pod，比如想要安装 pstree，那么可以先提前在网上把对应系统版本和架构的安装包下载到本地自己的开发环境，然后通过 kubectl cp 把下载到的安装包 cp 到 Pod 内，再在 Pod 内进

因为公司 k8s 容器集群的网络模式的问题，在 MacVlan 下，Pod 内会有两个网卡出现，Pod IP 是 eth0，MavVlan IP 是 eth1，然而 Dubbo 框架在选择网卡的时候会默认拿到 eth0，这样就会有一些网络问题，例如把 Pod IP 注册了，但是流量无法和集群外的网络互通。走读了一下 Dubbo 的代码，发现 isPreferredNetworkInterface 这个函数的配置是可以帮助 Dubbo 获取期望的网卡的，具体就是给 Dubbo 启动的时候加上一个参数 dub

最近在 Rancher 集群上部署一个应用的时候，因为使用了 Hostpath，并且创建了一个文件，按照 FileOrCreate 的模式创建的，常理来说，如果母机上没有这个文件，应该是可以创建出来的，但是在 Rancher 的集群上部署的时候就出了一个比较奇怪的情况，预期的文件，竟然变成了文件夹，一开始以为是参数有问题，反复看了几遍官方文档，感觉还是没啥问题。于是检索一下相关的 issue，果然发现了 HostPath volume type: FileOrCreate creates a directo

Overview因为 nightingale 官方没有提供 Helm Charts，这里根据团队实现的方式，提供了一个比较简单，容易理解的 Helm 包，nightingale-helm 可以参考下面的部署命令进行部署，细节主要参考 values.yaml 文件，很多配置，包括告警脚本都是通过 ConfigMap 来挂载到容器的，注意一下逻辑。因为nightingale需要依赖MySQL和Redis，所以提供了容器化的数据库来进行部署，数据库的初始化是通过k8s Job来实现的，同时也支持外部存储告

生产和测试环境维护了两套 Harbor 仓库，准备做镜像同步，要实现这样的功能，首先得是两边环境网络是通的，通过临时的网络策略放开了，然后就是至少两边互相 docker login 对方的 registry 应该也需要成功，但是有个奇怪的问题出现了。生产环境 docker login 测试环境的 registry OK，但是反过来却不行，意味着无法做镜像同步。一开始怀疑是有些特殊端口没通（只开放了80端口），联系运维的同学，把 ip 对 ip 的所有端口都开放了，还是失败了，抓包发现生产环境会主动断开连

rancher的编译-2接上一篇，rancher的编译-1，因为整个 rancher 是有 Makefile 的，所以正常来说一个 make 命令也可以让你进行编译。执行一下 make 然后报错了。Step 12/43 : RUN zypper -n install gcc binutils glibc-devel-static ca-certificates git-core wget curl unzip tar vim less file xz gzip sed gawk iproute2 ip

rancher的编译是用的自研的一个wrapper类型的工具, 这个工具本质上不复杂，就是通过docker来编译软件。仔细分析一下 rancher 的编译，其实也无非是众多的脚本累加到一起的非常复杂（甚至过于复杂）的东西，但既然沉淀下来，就大概搞明白编译是怎么做的，不然后面要进行改造的时候，可能会遇到一些坑。习惯性的关注文档里关于编译的说明，其实说的蛮清楚的了，通过 make 去执行 /scripts 下面的脚本，具体的顺序大概如下。make/scripts下面的脚本./.dapper ci默

可以看到执行了 kubeadm init 之后，貌似一直卡住 kubelet 这个进程的健康检查上，日志如下。[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"I1031 14:44:25.770815 10034 local.go:65] [etcd] wrote Static Pod manifest for a local etcd member to "/etc/kubernete

参考官方文档检查网络接口。检查唯一性。cat /sys/class/dmi/id/product_uuidiptables 的配置。cat <<EOF | sudo tee /etc/modules-load.d/k8s.confbr_netfilterEOFcat <<EOF | sudo tee /etc/sysctl.d/k8s.confnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-n

Rook 目前已经是 Ceph 官方文档推荐的 Kubernetes 部署 Ceph 集群的方式了。本文主要记录一下部署的过程和遇到的一些问题。# The deployment for the rook operator# Contains the common settings for most Kubernetes deployments.# For example, to create the rook-ceph cluster:kubectl create -f common.yamlku

Kind 是什么？ 这里就不复读了，大家可以直接查看官方文档，下面是我使用 Kind 碰到的问题，和解决的过程。# linux环境下下载curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.10.0/kind-linux-amd64chmod +x ./kind查看一下 kind 的 help 文档。➜ k8s ./kindkind creates and manages local Kubernetes clusters using Docker c

之前走读 Spark Opeartor Webhook 部分的代码的时候发现，因为业务种类很多，我们需要在 webhook 层加很多参数和配置来控制用户的一些行为但是发现原生的 Spark Operator 只接受 NamespaceSelector 也就是这种行为的控制职能针对一个命名空间的对象。这个范围对我们来说有点太大了，我们喜欢更精细一点去控制 Webhook 的效果，所以这里可以通过修改 Webhook，引入 ObjectSelector 来控制。修改 spark-operator webhook

阅读本文可能需要有手动部署 Ceph 集群的经验。Rook 本身很复杂，包含很多 Controller，而 Rook 的复杂不仅体现在这里，并且 Ceph 也非常复杂，在部署和运维上有很多需要注意的地方。本文主要剖析 Rook 启动 osd 的流程，如果有部署过 Ceph 的经验，应该知道加入 osd 大概有两个步骤，1是先 prepare，也就是检查节点上的一些设备是否符合安装 osd，2是激活，也就是 activate。这个过程在 Rook 里也同样需要。下面是部署完毕后的 Operator 和.

Unable to use a fieldSelector with custom resources #51046，按照这个 issue 的说法，CRDs 还不支持除了 name

现网有好几个 Luminous 的集群，因为指导 Rook 可以用来管理外部集群，所以想尝试一下。外部集群的概念是指，通过部署 Rook，来管理部署在其他集群或者物理机的 Ceph 集群，也就是 Rook 里 External Cluster 的概念。// pkg/operator/ceph/cluster/cluster_external.go// 先是判断 CephCluster 自定义资源的 Spec 字段有没有 CephVersion 和 DataDirHostPath 字段func val

之前写过一篇【Kubernetes】Octant部署，刚使用的时候觉得跟 Kubernetes Dashboard，用起来之后发现还是有挺多不同的，而且也确实跟 Octant

去年 InfoQ 上发表了一篇 Octant: Local and Real-Time Dashboard for Kubernetes Workloads，Octant 是 VMvare 开源的类似 Kubernetes Dashboard 最近尝试在集群里部署了一下。

文章目录1 java.lang.ClassNotFoundException: xsbt.CompilerInterface2 Unable to find: dev/checkstyle-suppressions.xml3 Unable to find configuration file at location scalastyle-config.xml4 Summary1 java.lang.ClassNotFoundException: xsbt.CompilerInterface改动了一下 S

今天发现用户的 pyspark 程序 driver 所在的母机的磁盘告警了，进去 pyspark driver pod 一看，发现有个目录数据多达1T了。一开始怀疑是 shuffle 文件没有清理干净，但通过 lsof 等命令查看是哪些进程在写，发现依然...

spark operator 是支持 webhook 的，也就是说，可以通过 webhook 来给 spark operator 创建的 pod 加上如 NodeSelector, PodAffinity, InitContainer 等特性。这在原生的 Spark 里只能通过配置 Pod Template 来做，个人觉得 Pod Template 不如 webhook 方便，而且 Spark 的逻辑里没有对 Pod Template 进行语法的校验。但是目前 // NamespaceSelector

如果有运行和监控 Kubernetes Operator 的经验的话应该知道，假设文中说的 Operator 都是 Spark Operator，那么作为管理员 ，可能需要经常到 k8s master 上 kubectl get sparkapp -n xxx 这种的操作，来看一下某个 namespace 下的 SparkApp 的情况，但是默认我们只能打出该 namespace 下所有的 SparkApp 的 Name 字段，显然这样是没什么意义的，比较有意义的，是需要知道哪些 SparkApp 是在运行

Spark on K8S 在 submit 的时候默认是直接在 K8S Master 节点提交，通过 --master 或者 SparkConf 中的 spark.master 来指定。The Spark master, specified either via passing the --master command line argument to spark-submit or by setting spark.master in the application’s configuration,

如果关注 Spark 社区的同学已经知道，从 Spark 3.0 开始，就不再支持用 Scala 2.11 来编译了，Scala 2.11 相关的依赖也被 Owen 去掉了，所以如果要用 Spark 3.0 的同学就需要用 Scala 2.12 去编译打包了。而如果还在用 Spark 2.x 版本的，至少在 2.4.5 的版本中，已经是将 Scala 2.12 作为默认的 Scala 版本了，如果用户的程序是用 Scala 2.11 写的，也需要将 Spark 用 Scala 2.11 编一次，而 Ma

我们的安卓容器需要使用 s3 来进行一些文件的上传和下载，因为 s3cmd 是 Python 写的，Android 系统中缺少linux系统中的这些依赖库，所以想运行 s3cmd，估计是不行的，如果需要使用静态编译的 s3 客户端程序，随手在 github 上搜了一个 s3-cli，这个项目是用 Go 写的，所以只要在本地编译的时候加上 static 就可以了。将原来项目点 Makefile 修改一下，在本地编译。SRC=*.gos3-cli: $(SRC) CGO_ENABLED=0 GOOS=

我们先看下 Spark

我们的任务流调度是采用 Airflow，画出 DAG 之后再按序执行，其中 Etcd 是我们很重要的组件，所以封装出一个 Airflow 的 Etcd Operator，然后将任务写到 Etcd，而在集群里有个 Watcher 的程序会监听 Etcd 任务的 key，一旦发现就会通过 Spark Operator 的 Spark Application Client 把任务提交到 api-server。...

今天在给 Executor 配置环境变量的时候，以为 Executor 环境变量跟 Driver 一样是通过 spark.kubernetes.driverEnv.XXX=YYY，最后发现其实是 spark.executorEnv，要注意 Env 的大小写，都是细节…可以看到下图，其实 Spark on Kubernetes 的文档，并没有写，所以 Executor 环境变量就是普通的参数即可。...

业务容器需要在 A 集群解析 B 集群的容器，已知 B 集群的 Pod 如果重启后，IP 会变化，所以在 B 集群创建 StatefulSet，并且创建 Headless Service，A 容器通过访问 B 集群这些服务的 ServiceName 来通信，因此 A 集群容器需要在访问 B 集群 ServiceName 的时候能够解析出 IP，所以这里通过给 B 集群的 kube-dns 创建负载均衡或者内网 IP，之后将内网 IP 写入 /etc/resolv.conf 文件中，在 A 集群创建 Conf