Day24-Kubernetes 那些事 - 内部架构

前言

之前的文章提到透过 K8s 的 Health Check，可以将不健康的 Pod 砍掉重建，或是确保 Pod 可以正常接收 Request，相信读者应该很好奇 K8s 到底是如何做到这些功能的，接下来笔者就来谈一下 K8s 内部架构。

kubelet

kubelet 用於管理该机器上的所有 Pod 状态以及与 Master 进行即时沟通，简单来说 kubelet 就是以管理员的身份存在，所有的 Pod 都是经过 kubelet 审核後才可以开始使用，所以在上一篇的 Health Check 提到：当 Pod 被 livenessProbe 侦测为不健康时，K8s 就会砍掉 Pod 并重建，而砍掉重建这段过程就是依赖 kubelet 完成的。

kube-proxy

kube-proxy 是用来实现 Service 功能，还记得在 Service 的文章提到，只要让 selector 选择到正确的 Pod Labels 就可以正确的连接到 Pod，但 Service 本身是没办法一次发多个 Request 到各个 Pod，当今天有多个 Pod 时 Service 要如何平均分散流量至各个 Pod，这段过程就是依赖 kube-proxy 来实现。

kube-proxy 一共有两种方式来实作：

• Userspace

  在学系统架构的时候相信读者一定很常听到 Kernelspace 以及 Userspace，Kernelspace 指的是系统内部核心要操作时的空间，举凡像是读写档案等等需要操作到系统的都会在这边运行，而 Userspace 能做的事情就比较少，只能做一些简单的逻辑运算等等，这些只需要耗费一些记忆体以及 cpu 资源就可以完成的就会在 Userspace 中运行。

  在 kube-proxy 中 Userspace 的实作通常是会监听一个 port，并把机器上所有的 Request 都转发到这个 port，然後 kube-proxy 再将转发至旗下的 Pod，整体看起来好像没什麽问题，但光一个 Service 就要经过这麽多层的转发想当然整体效率也会很差，所以现阶段 kube-proxy 都不是用 Userspace 的方式实作。

• iptables

  iptables 则是使用 linux 的 iptables 进行实作，透过 iptables 的 netfilter 可以快速地进行网路位址转换，也因为这个特性，所以可以让一个 Service 代理非常多的 Pod，反正过程都会藉由 iptables 来进行网路位址转换，让整体效率提升许多省去很多转发的过程，这也是目前 K8s 预设的实作方式。

  

container runtimes

container runtimes 则是 K8s 负责让 Pod 内运行 container 的方法，K8s 支援非常多的实现方法有：Docker、containered、CRI-O，通常都是用 Docker 进行 Pod 内运行 container。

Addons

还记得先前笔者所介绍的 Ingress 文章吗？里面有提到 addons，但那时候只是轻描淡写带过而已，其实 addons 在 K8s 中代表的就是插件的意思，K8s 有非常多的插件可以使用，只要把插件内的某个功能 enable 起来就可以使用了，所以像是 Ingress、以及 HPA 文章时所介绍的 metrics-server 都是利用这种方式打开。

谜之声：只有 minikube 这麽搞刚要各项打开，上云端都开好好不用自己手动开了XD

DNS

不晓得大家在之前笔者介绍 Ingress 的时候有没有好奇一点，为什麽可以直接写上 ServiceName 这样就可以自动找到对应的 Service，有点像是在浏览器打上 https://www.google.com/ 就会自动接到 Google 的服务器一样，相信读者都知道所有的连线沟通都必须要依赖网路，没有一个对应的 IP 就没办法连接到对应的服务，所以 K8s 内部也有一套 DNS 系统，方便 Pod 与 Service 之间互相沟通，而这套系统就叫：kube-dns。

小结

今天介绍了 K8s 的内部架构，相信读者应该更了解 K8s 是如何处理内部的相关内容，先前疑惑的点可能也在这次的文章都有了答案。

接下来要介绍的内容不一定每位读者都会用到，但其实也是蛮重要的观念，如果有任何问题都欢迎留言给我，那我们就下篇文章见喽～