DevPod on Kubernetes: turning devcontainer.json into a persistent remote workspace
DevPod is an open source workspace manager for reproducible development environments across Docker, Kubernetes, SSH hosts, and s…
阅读全文Replacing Docker Desktop with Colima on macOS
Colima is one of the cleanest ways to run containers locally on macOS. It starts a Linux virtual machine through Lima, runs Dock…
阅读全文Kubernetes GPU Sharing
GPU sharing in Kubernetes depends on what the NVIDIA device plugin advertises to the scheduler, what isolation the underlying me…
阅读全文Investigating and Solving the Issue of Failed Certificate Request with ZeroSSL and Cert-Manager
In this blog post, I will walk through my journey investigating and resolving an issue where my certificate request from ZeroSSL…
阅读全文Kubernetes Migration
Migrating a Kubernetes cluster from one cloud provider to another usually breaks into three separate problems: moving Kubernetes…
阅读全文Terraform: a practical guide to infrastructure as code
Terraform is an infrastructure-as-code tool. You describe the target infrastructure in configuration files, and Terraform compar…
阅读全文编写Kubernetes风格的APIServer
前段时间接到一个需求做一个工具,工具将在K8S中运行。需求很适合用控制器模式实现,很自然的就基于kubebuilder进行开发了。但是和K8S环境提供方沟通时发现,他们不允许工作负载调用控制平面的接口,这该怎么办呢。
最快速的解决方案是,自己运行一套ku…
阅读全文记录一次KeyDB缓慢的定位过程
这个问题出现在一套搭建在虚拟机上的Kubernetes 1.18集群上。集群有三个节点:
|
1 2 3 4 5 |
# kubectl get node -o wide NAME STATUS VERSION INTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME 192.168.104.51 Ready v1.18.3 192.168.104.51 CentOS Linux 7 (Core) 3.10.0-862.3.2.el7.x86_64 docker://19.3.9 192.168.104.72 Ready v1.18.3 192.168.104.72 CentOS Linux 7 (Core) 3.10.0-862.3.2.el7.x86_64 docker://19.3.9 192.168.104.108 Ready v1.18.3 192.168.104.108 CentOS Linux 7 (Core) 3.10.0-862.3.2.el7.x86_64 docker://19.3.9 |
KeyDB通过StatefulSet管理,一共有三个实例:
|
1 2 3 4 5 |
# kubectl -n default get pod -o wide -l app.kubernetes.io/name=keydb NAME READY STATUS RESTARTS IP NODE keydb-0 1/1 Running 0 172.29.2.63 192.168.104.108 keydb-1 1/1 Running 0 172.29.1.69 192.168.104.72 keydb-2 1/1 Running 0 172.29.1.121 192.168.104.51 |
这三个实例:
- 由于反亲和设置,会在每个节点上各运行一个实例
- 启用Active - Active(--active-replica)模式的多主(--multi-master)复制 :每个实例都是另外两个的Slave,每个实…
IPVS模式下ClusterIP泄露宿主机端口的问题
在一个启用了IPVS模式kube-proxy的K8S集群中,运行着一个Docker Registry服务。我们尝试通过docker manifest命令(带上--insecure参数)来推送manifest时,出现TLS timeout错误。
这个Registry通过ClusterIP类型的Service暴露访问端点,且仅仅配置了HTTP/80端口。docker manifest命令的--insecure参数的含义是,在Registry不支持HTTPS的情况下,允许使用不安全的HTTP协议通信。…
阅读全文内核缺陷触发的NodePort服务63秒延迟问题
我们有一个新创建的TKE 1.3.0集群,使用基于Galaxy + Flannel(VXLAN模式)的容器网络,集群由三个二层互通的Master节点 10.0.0.11、 10.0.0.12、 10.0.0.13组成。在访问宿主机端口为 30153的NodePort类型的Service时,出现了很有趣的现象:
- 在节点 10.0.0.11、 10.0.0.13节点上 curl http://localhost:30153,有50%几率卡住
- 在节点,100%几率卡住
- 从集群内部,访问非本节点的30153端口,畅通
- 从集群外部,访问任意节点的30153端口,畅通
三个节点本身并无差异,卡住几率不同,可能和服务的端点(Endpoint,即Pod)的分布情况有关。
NodePort服务的定义如下:
该服务的端点有两个:
可以看到,端点在10.0.0.11、10.0.0.13上分别有一个。假设容器网络存在问题,只能访问本机的Pod,则能解释前面的卡住现象 —— 10.0.0.12上没有端点,因此一直卡住。10.0.0.11、10.0.0.13分别占有50%端点,因此50%几…
阅读全文