Daily Archives: 2020年7月19日

k8s基本网络模型 约法三单 pod之间可以直接通信，无需显式使用NAT接收和地址转换 node与pod之间可以直接通信，无需要明显地址转换 pod可以看到自己的ip跟别人看到它所用的ip是一样的，中间不经过转换 分类 underlay：与Host网络同层 ovrelay：只要与Host网络不冲突，ip可以自由分配 Kubenets Service Service工作原理： 通过kube-proxy设置宿主机iptables规则来实现，kube-proxy通过观察service的创建，然后通过修改本机的iptables规则，将访问service vip的请求转发到真实的Pod上。 基于iptables规则的service的实现，宿主机上有大量Pod时，规则的不断刷新占用大量CPU资源，新的模式：ipvs，通过把规则放到内核态，降低了维护规则的代价 Service的DNS记录：<myservice>.<mynamespace>.svc.cluster.local，访问这条记录时，返回的是Service的VIP或代理Pod的IP地址集合 Pod的DNS记录：<pod_hostname>.<subdomain>.<mynamespace>.svc.cluster.local，注意pod的hostname和subdomain都是在Pod中定义的 集群内访问 环境变量 Headless ServiceclusterIP: None不再提供虚拟IP来负载均衡 集群外访问（外部宿主机访问） NodePort：外部client访问任意一台宿主机的8080端口，就是访问Servicer所代理的Pod的80端口，由接收外部请示请求的宿主机做转发，即client -> nodeIP:nodePort -> serviceVIP:port -> podIp:targetIp LoadBalance：公有云提供的k8s服务自带的loadbalancer做负载均衡和外部流量 的入口 ExternalName：通过ExternalName或ExternalIp给Service挂在一个公有IP或者域名，当访问这个公有IP地址时，就会转发到Service所代理的Pod服务上。类似于软链或快捷方式 ClusterIP：虚拟IP地址，外部网络无法访问，只有k8s内部访问使用。更像是一个伪造的IP网络 仅仅用于Service这个对象，并由k8s管理和分配IP地址 无法被Ping通，没有一个“实体网络对象”来响应 只能结合Service Port组成一个具体的通信端口，单独的ClusterIP不具备通信的基础，并且它们属于k8s集群这样一个封闭的空间 不同Service下的Pod节点在集群间相互访问可以通过ClusterIP Service与Ingress Ingress：全局的、为了代理不同后端Sercie而设置的负载均衡服务，只能工作在7层，而service工作在四层 … Continue reading →