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…
阅读全文K8S集群跨云迁移
要将K8S集群从一个云服务商迁移到另外一个,需要解决以下问题:
- 各种K8S资源的迁移
- 工作负载所挂载的数据卷的迁移
- 工作负载所使用的镜像的迁移
K8S资源、数据卷的迁移,可以考虑基于Velero项目。镜像仓库的迁移较为简单,可供选择的开源工具包括阿里云的image-syncer、腾讯云的image-transfer。
Terraform快速参考
Terraform用于实现基础设施即代码(infrastructure as code)—— 通过代码(配置文件)来描述基础设施的拓扑结构,并确保云上资源和此结构完全对应。Terraform有三个版本,我们主要关注Terraform CLI。
Terraf…
阅读全文编写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%几…
阅读全文Galaxy学习笔记
Galaxy是TKEStack的一个网络组件,支持为TKE集群提供Overlay/Underlay容器网络。Galaxy的一个特性是能够提供浮动IP(弹性IP) —— 即使Pod因为节点宕机而漂移到其它节点,其IP地址也能够保持不变。
Galax…
阅读全文Istio中的透明代理问题
Istio的Sidecar作为一个网络代理,它拦截入站、出站的网络流量。拦截入站流量后,会使用127.0.0.1作为源地址,将流量转发给本地服务进程。本地服务进程看不到真实源IP地址。
很多应用场景下,真实源IP地址是必须的,可能原因包括:
- I…
Cilium学习笔记
Cilium是在Docker/K8S之类的容器管理平台下,透明的为应用程序服务提供安全网络连接的开源软件。Cilium的底层技术是eBPF,eBPF完全在内核中运行,因此改变Cilium的安全策略时不需要程序代码、容器配置的任何变更。