Kubernetes网络

Service 存在的意义

Service引入主要是解决Pod的动态变化，提供统一访问入口：

防止Pod失联，找到提供同一个服务的Pod（服务发现）

定义一组Pod的访问策略（负载均衡）

Pod与Service的关联

Service通过标签关联一组Pod

Service为一组提供负载均衡能力

Service定义与创建

创建service

kubectl create service clusterip web --tcp=80:80

或

导出成yaml文件

kubectl create service clusterip web6 --tcp=80:8080 --dry-run=client -o yaml > service.yaml

然后执行

kubectl apply -f service.yaml

查看service：

kubectl get service

定义service.yaml

apiVersion: v1

kind: Service

metadata:

name: web

spec:

type: ClusterIP # 服务类型

ports:

- port: 80

protocol: TCP

# Service端口

# 协议

targetPort: 80 # 容器端口（应用程序监听端口）

selector:

app: web

# 指定关联Pod的标签

多端口Service定义：

对于某些服务，需要公开多个端口，Service也需要配置多个端口定义，通过端口名称区分

Service三种常用类型

ClusterIP：

默认， 分配一个稳定的IP地址，即VIP，只能在集群内部访问。

NodePort：

在每个节点上启用一个端口来暴露服务，可以在集群外部访问。也会分配一个稳定内部集群IP地址。

访问地址：

<任意NodeIP>:<NodePort>

端口范围：

30000-32767

NodePort：

会在每台Node上监听端口接收用户流量，在实际情况下， 对用户暴露的只会有一个IP和端口，那这么多台Node该使

用哪台让用户访问呢？

这时就需要前面加一个公网负载均衡器为项目提供统一访问入口了。

user -> 公网负载均衡器 -> service nodeport 30001 -> 分布各节点pod

user -> 公网负载均衡器 -> service nodeport 30002 -> 分布各节点pod

user -> 公网负载均衡器 -> service nodeport 30003 -> 分布各节点pod

userspace

LoadBalancer：

与NodePort类似，在每个节点上启用一个端口来暴露服务。除此之外， Kubernetes会请求底层云平台（例如阿里云、腾

讯云、 AWS等）上的负载均衡器，将每个Node（[NodeIP]:[NodePort]）作为后端添加进去。

Service代理模式

Service的底层实现主要有iptables和ipvs二种网络模式，决定了如何转发流量

二进制方式修改ipvs模式：

# vi kube-proxy-config.yml

mode: ipvs

ipvs:

scheduler: "rr“

# systemctl restart kube-proxy

注：配置文件路径根据实际安装目录为准

kubeadm方式修改ipvs模式：

kubectl edit configmap kube-proxy -n kube-system

注意：

1、 kube-proxy配置文件以configmap方式存储

2、如果让所有节点生效，需要重建所有节点kube-proxy pod

删除之后会自动拉起

然后再node节点上查看是否启用了ipvs规则

流程包流程：客户端 ->NodePort/ClusterIP（iptables/Ipvs负载均衡规则） -> 分布在各节点Pod

查看负载均衡规则：

o iptables模式

iptables-save |grep <SERVICE-NAME>

o ipvs模式

ipvsadm -L -n

Iptables 与 IPVS对比

Iptables：（适合小规模）

o 灵活，功能强大

o 规则遍历匹配和更新，呈线性时延

IPVS：（适合大规模）

o 工作在内核态，有更好的性能

o 调度算法丰富： rr， wrr， lc， wlc， ip hash，更高效

Service DNS名称

CoreDNS：是一个DNS服务器， Kubernetes默认采用，以Pod部署在集群中。

CoreDNS服务监视Kubernetes API，为每一个Service创建DNS记录用于域名解析。

ClusterIP A记录格式：

<service-name>.<namespace-name>.svc.cluster.local

示例： my-svc.my-namespace.svc.cluster.local

Ingress为弥补NodePort不足而生

NodePort存在的不足：

o 一个端口只能一个服务使用，端口需提前规划

o 只支持4层负载均衡

Ingress是什么

o Ingress： K8s中的一个抽象资源，给管理员提供一个暴露应用的入口定义方法

o Ingress Controller： 负责流量路由，根据Ingress生成具体的路由规则，并对Pod负载

均衡

Ingress Controller是什么？

Ingress管理的负载均衡器，为集群提供全局的负载均衡能力。

使用流程：

1. 部署Ingress Controller

2. 创建Ingress规则

Ingress Controller有很多实现，我们这里采用官方维护的Nginx控制器。

项目地址： https://github.com/kubernetes/ingress-nginx

修改YAML里镜像地址为国内的： lizhenliang/ingress-nginx-controller:v1.1.0

其他控制器： https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/

暴露Ingress Controller两种方式：

Service NodePort暴露Ingress Controller

共享宿主机网络（ hostNetwork:True ）

Ingress 规则配置

创建：

kubectl apply -f xxx.yaml

查看：

kubectl get ingress

测试：本地电脑绑定hosts记录对应ingress里面配置的域名

例： <Ingress Controller Pod所在Node IP> web.aliangedu.cn

Ingress 规则配置： HTTPS

上传证书文件和 certs.sh脚本

加压后执行脚本

配置HTTPS步骤：

1、准备域名证书文件（来自： openssl/cfssl工具自签或者权威机构颁发）

2、将证书文件保存到Secret

3、 Ingress规则配置tls

修改yaml文件

Ingress Controller怎么工作的？

Ingress Controller通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段 Nginx 配置，应用到管理的Nginx服务，然后热加载生效。以此来达到Nginx负载均衡器配置及动态更新的问题。

流程包流程：客户端 ->Ingress Controller（nginx） -> 分布在各节点Pod

四层（传输层）：基于IP和端口进行转发

七层（应用层）：基于应用层协议转发，例如HTTP：域名、URL等

service，背后有iptables实现

ingress，背后有ingress controller（内部是有个负载均衡技术，是什么？）实现

kube-proxy = ingress controller

访问流程1：

用户（域名） -> 公网负载均衡器 80,443 -> 所有宿主机 service nodeport -> ingress controller（nginx，基于域名） -> 分布在各个节点的pod

注： 增加service（iptables）转发，提高一点时延

访问流程2：

用户（域名） -> 公网负载均衡器 80,443 -> 指定宿主机 ingress controller（nginx，基于域名） -> 分布在各个节点的pod

注：域名必须得解析到ingress controller pod所在的节点ip

公网负载均衡器用途：

1、将内网k8s集群的service、ingress暴露到互联网

2、提高内网k8s集群安全性

nginx-ingress-controller 主要用于访问k8s api获取创建的ingress规则，生成nginx vhost配置并生效

nginx 就是nginx本尊，做了一些优化和功能加强