1. 容器网络是什么样的网络
forewords
这章的一开头有一句很有意思的话, 他们说云时代不会再有企业消耗巨资去打造自己的IT, 我对这句话的理解是中小企业里原先搞IT的那些人, 现在负责去折腾上云, 以及折腾那些层出不穷的新服务. 对于大企业而言, 这部分巨资则被拿去研究K8s以及周边云服务去了, 换句话说你原先用于IT系统的钱现在不过是拿去买云服务/折腾云服务了, 具体你能不能省下钱, 我不确定. 但对于我们开发者来说, 能参与一次集体上云的变革总归是好消息
我们已经知道了容器good good, 那么下一步自然就是自动化/流水线化容器管理, 这也就是大家天天嘴里念经一般的"容器编排", 无论他有没有过很深刻的理解, kubexxx源码先撸一遍, "我看过源码!" 这句话就是程序员的圣旨, 的确看源码, 很屌, 但我觉得更重要的是你需要对需求/难点/玩法/方案, 有深刻的理解, 这应该(绝对)比看过源码更重要吧?
introduction
kubernetes帮助我们把容器安排到不同的机器上并开始提供服务, 这个过程我们叫做部署. k8s提供一种大规模部署/编排/管理(增删改查)容器的能力, 能做到我们想要的容器流水线的那种效果. 所有k8s的特性都是围绕这种 容器流水线而展开的 , 那么相对应的我们也会有流水线上的组件, 包含有: 镜像仓库(harbor), 网络插件(cni), 监控(kibana), 存储(torus), 为这条容器流水线提供服务. k8s一个特点是组件化, 每一个组件都起一个叫kube_xxx
的名字, 新人入门的时候这些花里胡哨的名词往往也相当劝退, 包含有:
Master(主节点): 控制从节点, 管理集群
Node(从节点): 在主节点的控制下, 将容器跑起来
Pod: 几个容器垒在一起叫pod, 负责跑一个"任务", 把这个任务拆成好几小块, 每个容器跑一小块. pod内虽然包含好几个小容器, 但是他们彼此相互关联, 他们可能会共享: pid/nns/ipc/vol
Service: 声明一种服务, 将这个服务映射到pod上, 这样你不用在乎真正跑任务的pod, 你只需要找这个服务就好
Kubelet: 从节点上运行的守护进程
Kubectl: 一个命令行工具, 帮助你管理集群用的
一个议题是, docker在里面是什么角色, 本来Docker控制这个机器上的cgroup之类的东西, 帮助你创建一个容器就完事儿了, 然后k8s控制docker往这个从节点上安排容器, 我们是这么安排的没错, 但是docker也想搞编排的事情, 这就不是它该操心的事儿了, 而且管的越多说实话就越不稳定, 可能到最后你连创建容器都没法很好的胜任了. 因此K8s也想过让类似 containerd/cri-o
等来替代docker做创建容器的任务
K8s网络包含那些东西?
因为本身想要猛攻K8s网络这边, 但是过度的deep-dive容易迷失方向搞昏头, 因此我们一定要知道这些东西都是拿来干嘛的, 大概想解决什么问题的, 然后我们针对这个问题开始讨论如何解决, 这种时候才需要步入细节开始讨论 :) K8s网络包含有以下几块内容:
Service: 集群内访问pod的服务
Ingress: 集群外访问Pod的服务
CNI: 负责(pause)容器内网络设备的初始化: eth0/为eth0分配IP, bridge/flannel等就负责做这个
DNS
K8s网络的基本问题是什么?
我们设想k8s的工作模式, 会基于一些前提下才能正常的开始工作, 比如说你希望: 某服务器上的所有容器都在一个指定的IP段下, 且不同服务器之间的IP段不会重叠, 这样你就可以依据某一个IP准确的指出这是哪一个容器, 这样我们就引入了K8s网络的核心问题:
比如一个节点加入集群了, 需要以某种方式给它分配IP段 - IP分配功能
为从节点(宿主机)分配IP: 节点上运行的proxy/kubelet需要跟主节点通信
为pod分配IP: 创建集群的时候指定IP段, 创建容器的时候就从这个段里拿出一个来用
为Service分配IP: 我们希望直接调用Service就能直接调用pod提供的服务, service对应一个IP
或者说pod对外发送一条消息的时候, 宿主机需要依据(私有)IP, 找到这个IP在那个节点上, 并传递过去 - 地址路由功能
pod与pod间通信: pod可以依据对方在集群内的IP找到/ping通对方, cni就是用于实现这些功能的接口
pod与service间通信: ClusterIP类型的Service会获得一个IP, 集群内别人通过这个IP找到这个服务, KubeProxy 负责从ip地址引流到pod的全过程, 使用的手段包含 iptable/ipvs
pod与集群外通信: 现在我们想要出集群了, K8s会通过SNAT来将容器的 ip:port 映射成宿主机的 ip:port, 外界做出响应的时候再将 ip:port 换回来, 然后发送给pod
Last updated
Was this helpful?