👋 Hi, there. I’m Kain

正常情况下节点会在同一专有网络内，而当使用公网建立的 k8s 集群中跨主机 pod 可能无法互通，此时需要检查几个方面进行调整： 使用 Flannel VXLAN 需要确保每个节点之间 8472/udp 可以互通 设置 --node-ip <ip> 值对应该节点的异地组网 IP 和 VPC 内网 IP 设置 --node-external-ip <ip> 值对应节点公网 IP Debian11 默认使用 nftables 而不是 iptables ，K3S 网络功能需要使用 iptables，而不能使用 nftables sudo iptables -F sudo update-alternatives --set iptables /usr/sbin/iptables-legacy sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy sudo reboot 为节点增加注解 flannel.alpha.coreos.com/public-ip-overwrite: <ip> 值对应该节点的异地组网 IP，如果节点都具备公网 IP 设置公网 IP 确保 coredns 能被每个节点正常访问

环境条件： UCloud 公网 Kubernetes 3 个 Pod 组成 Nats 集群，每个 Pod 分别编排至不同的 Node(2C4G) 测试 1 1 个发布者，发布每条 16B 共 1000000 条的信息 1 个订阅者，订阅生成的 1000000 条信息 $ nats bench bar --js --pub 1 --size 16 --msgs 1000000 -s nats://s1.kainonly.com:4222,nats://s2.kainonly.com:4222,nats://s3.kainonly.com:4222 --nkey ./weplanx.key 10:37:39 Starting JetStream benchmark [subject=bar, msgs=1,000,000, msgsize=16 B, pubs=1, subs=0, js=true, stream=benchstream, storage=memory, syncpub=false, pubbatch=100, jstimeout=30s, pull=false, consumerbatch=100, push=false, c onsumername=natscli-bench, replicas=1, purge=false, pubsleep=0s, subsleep=0s] 10:37:40 Starting publisher, publishing 1,000,000 messages Finished 3m11s [=======================================================================================================================================================================================================] 100% Pub stats: 5,210 msgs/sec ~ 81....

将此添加到您的中 ~/.bashrc if [ ! -S /run/ssh-agent.socket ]; then eval "$(ssh-agent -s -a /run/ssh-agent.socket)" ssh-add ~/.ssh/id_rsa fi export SSH_AUTH_SOCK=/run/ssh-agent.socket

问题描述 在节点处于“不可用”状态时，CCE 会迁移节点上的容器实例，并将节点上运行的 pod 置为“Terminating”状态。 待节点恢复后，处于“Terminating”状态的 pod 会自动删除。 偶现部分 pod（实例）一直处于“Terminating ”状态： 通过 kubectl delete pods -n 命令始终无法将其删除： kubectl delete pods aos-apiserver-5f8f5b5585-s9l92 -n aos 解决方法 无论各种方式生成的 pod，均可以使用如下命令强制删除： kubectl delete pods <pod> --grace-period=0 --force 因此对于上面的 pod，我们只要执行如下命令即可删除： kubectl delete pods aos-apiserver-5f8f5b5585-s9l92 --grace-period=0 --force

WebDAV ，全称是 Web-based Distributed Authoring and Versioning，维基百科上对它的解释是这样的：基于 Web 的分布式编写和版本控制（WebDAV）是超文本传输协议（HTTP）的扩展，有利于用户间协同编辑和管理存储在万维网服务器文档。 使用原因 类似技术，我们常见的是文件传输协议(FTP)，他在 RFC 959 中定义，于 1985 年 10 月发布，被设计成为一个跨平台的、简单且易于实现的协议。但时至今日，却已江河日下，因为存在一些历史问题，大致以一下几点： 密码安全策略不完善 与防火墙工作不协调 无法对操作进行细化处理 效率不高，速度较慢 与 FTP 相比，WebDAV 具有以下优点： 通过一个 TCP 连接，可以更轻松地将其配置为绕过防火墙，NAT 和代理。 在 FTP 中，数据通道可能会导致正确的 NAT 设置出现问题。 同样，由于一个 TCP 连接可以持久，因此在传输许多小文件时，WebDAV 将比 FTP 快一点-无需为每个文件建立数据连接。 GZIP 压缩是 HTTP 的标准，但不是 FTP 的标准（是的，FTP 中提供了 MODE Z，但未在任何标准中定义）。 HTTP 有很多未在 FTP 中定义的身份验证方法。 例如。 NTLM 和 Kerberos 身份验证在 HTTP 和 FTP 中很常见，除非您同时编写 FTP 的客户端和服务器端，否则很难获得对它们的适当支持。 WebDAV 支持部分传输，在 FTP 中无法部分上传（即，您不能覆盖文件中间的块）。 因此 WebDAV 是一个替代 FTP 不错的方案...