Kubernetes 网络模型
K8S 是一种容器编排系统,可以方便地管理和部署容器应用程序。它支持通过四层负载和七层负载向容器集群中的应用程序提供负载均衡。
四层负载是一种基于传输层协议(例如TCP、UDP)的负载均衡方式,可以将来自客户端的请求均匀地分配给多个容器实例,以实现应用程序的高可用性和可伸缩性。K8S 中的四层负载均衡是通过内置的 kube-proxy 实现的,它可以将请求路由到不同的容器实例中,以实现负载均衡和故障转移。
七层负载是一种基于应用层协议(例如HTTP、HTTPS)的负载均衡方式,可以在不同的应用层流量之间进行智能路由,以提高应用程序的性能和可用性。K8S 中的七层负载均衡通常使用 Ingress Controller 实现,它可以监控集群中的 Ingress 资源,并自动配置负载均衡器来路由流量。 Ingress Controller 可以支持多种负载均衡算法(例如轮询、加权轮询、ip_hash等),也可以支持SSL终止、Websocket等高级功能
Kubernetes 对网络设施的基本要求
Pod 能够与所有其它节点上的 Pod 相互通信, 且不需要网络地址转译(NAT)
节点上的代理(比如:系统守护进程、kubelet)可以和节点上的所有 Pod 相互通信
Kubernetes 网络解决四方面的问题
Pod中的容器之间可以通过本地回路(loopback)相互通信
集群网络在不同 Pod 之间提供通信
Service API 允许向外暴露 Pod 中运行的应用, 以支持来自于集群外部的访问
Ingress 提供专门用于暴露 HTTP 应用程序、网站和 API 的额外功能
Service
-
K8S 可以保证任意 Pod 挂掉时自动从任意节点启动一个新的Pod进行代替,以及某个Pod超负载时动态对Pod进行扩容。每当 Pod 发生变化时其 IP地址也会发生变化,且Pod只有在K8S集群内部才可以被访问,为了解决Pod发生变化导致其IP动态变化以及对外无法访问的问题,K8S引进了 Service 的概念
-
K8S 使用 Service 来管理同一组标签下的 Pod ,当外界需要访问 Pod 中的容器时,只需要访问 Service 的这个虚拟 IP 和端口,由 Service 把外界的请求转发给它背后的Pod
Service暴露服务类型
1、ClusterIP(默认)
- 自动为当前Service分配虚拟IP,在不重启Service前提下该IP是不会改变的,只能在集群内部访问
2、NodePort
- 需要在K8S集群的所有 Node 节点上开放特定的端口【30000-32767】,通过(公网ip : 端口)访问Service服务。缺点:每个端口只能挂载一个Service,从安全角度讲开放更多的端口是存在一定风险的,从维护角度讲开放的端口越多维护的成本越大
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
selector:
app.kubernetes.io/name: MyApp
ports:
- port: 80
targetPort: 80
nodePort: 30007
3、LoadBalancer
-
和Nodeport相似,目的都是向外暴露一个端口,但 LoadBalancer 模式需要开发者在K8S集群外部的公有云服务器上做一个负载均衡设备(当前主流的阿里云、腾讯云、华为云、微软云等等厂商都有提供相关收费的服务),外部服务发送到公有云服务上的请求都会被负载并转发到K8S集群中LoadBalancer服务上
-
如果要在私网环境下测试LoadBalancer,必须要创建一个MetalLB, MetalLB相当于一个负载均衡器的角色
-
LoadBalancer原理:外部请求首先被转发到外部LB负载设备,再通过匹配规则转发到k8s集群的任意node节点上,最终通过Service资源找到对应的pod
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
clusterIP: 10.0.171.239
type: LoadBalancer
status:
loadBalancer:
ingress:
- ip: 192.0.2.127
4、ExternalName
- 通过返回 CNAME 记录和对应值,可以将服务映射到 externalName 字段的内容(例如:foo.bar.example.com),无需创建任何类型代理
注意:需要使用 kube-dns 1.7 及以上版本或者 CoreDNS 0.0.8 及以上版本才能使用 ExternalName 类型
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: prod
spec:
type: ExternalName
externalName: my.database.example.com
Service代理模式
Service 创建成功后会通过 api-server 向 etcd 中写入相关配置信息,kube-proxy会监听创建好的配置信息并将最新的service配置信息转化成对应的访问规则,最终实现外网对Pod的访问。常见的service访问规则有:iptables 和 ipvs
1、iptables
kube-proxy 为 service 后端的每个Pod创建对应的iptables规则,当用户访问ClusterIP时,直接将发送到ClusterIP的请求重定向到Pod
缺点:kube-proxy 不承担四层路由转发的角色,只负责创建iptables规则,无法实现LB策略
2、ipvs(性能高于iptables)
kube-proxy 监控Pod的变化并创建相应的ipvs规则,当用户访问ClusterIP时,直接将发送到ClusterIP的请求重定向到Pod
相比于iptables,支持LB策略
3、切换到IPVS模式
kubectl get pod -o wide -n kube-system | grep kube-proxy
kubectl logs -n kube-system kube-proxy-7bst7
apt install -y ipvsadm ipset
ipvsadm -Ln
- 切换Sevice代理模式为ipvs(K8S集群的Master节点修改)
kubectl edit configmap kube-proxy -n kube-system
kubectl get pod -o wide -n kube-system | grep kube-proxy
kubectl delete pod kube-proxy-7bst7 -n kube-system
kubectl delete pod kube-proxy-9l7qr -n kube-system
kubectl delete pod kube-proxy-cqht2 -n kube-system
kubectl delete pod kube-proxy-h8znm -n kube-system
kubectl delete pod kube-proxy-l4p42 -n kube-system
kubectl delete pod kube-proxy-xlqtg -n kube-system
4、验证IPVS
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
calico-typha ClusterIP 10.96.26.184 <none> 5473/TCP 13d k8s-app=calico-typha
kube-dns ClusterIP 10.96.0.2 <none> 53/UDP,53/TCP,9153/TCP 13d k8s-app=kube-dns
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.96.0.1:443 rr
-> 192.168.111.30:6443 Masq 1 1 0
-> 192.168.111.31:6443 Masq 1 1 0
-> 192.168.111.32:6443 Masq 1 1 0
TCP 10.96.0.2:53 rr
-> 10.244.166.141:53 Masq 1 0 0
UDP 10.96.0.2:53 rr
-> 10.244.166.141:53 Masq 1 0 0
TCP 10.96.0.2:9153 rr
-> 10.244.166.141:9153 Masq 1 0 0
TCP 10.96.26.184:5473 rr
-> 192.168.111.40:5473 Masq 1 0 0
Service - 部署Nginx应用并对外访问
方式1:创建deployment并将其显示为Service
kubectl create ns dev && kubectl get ns dev
kubectl create deployment nginx --image=nginx --replicas=1 -n dev
kubectl expose deployment nginx --name=nginx --type=NodePort --port=8080 --target-port=80 -n dev
kubectl get deployment,pods,service -n dev -o wide
kubectl logs -n dev nginx-748c667d99-phdxv
kubectl describe -n dev pod nginx-748c667d99-phdxv
方式2:创建Service(yaml文件)
注意:基于Kubernetes Pod和工作负载文章已创建好的资源进行演示
vi service-nginx.yaml
apiVersion: v1
kind: Service
metadata:
namespace: dev
name: nginx
labels:
app: nginx
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 8080
targetPort: 80
kubectl create -f service-nginx.yaml
kubectl delete -f service-nginx.yaml
kubectl get deployment,replicaSet,pods,service -n dev -o wide --show-labels
curl 10.244.104.10:80
curl 10.244.166.157:80
curl 10.96.73.217:8080
http://192.168.111.40:30000
http://192.168.111.41:30000
http://192.168.111.42:30000
Ingress
ingress是k8s集群的请求入口,可以理解为对多个service的二次抽象,一般包括ingress资源对象及ingress-controller两部分
Ingress(k8s内置的资源对象)
- Ingress 是 k8s 的资源对象,用于定义外部的(HTTP 和 HTTPS)请求如何转发到 Service 服务的规则
ingress-controller(需要单独安装)
-
ingress-controller 不是 k8s 自带的组件,只是一个统称,可以选择不同的 ingress-controller 实现对 service 的反向代理及负载均衡,常用的 ingress-controller 产品有:F5 Networks、Kong、Traefik、NGINX、HaProxy、Istio
-
ingress-controller 本质是一个 pod,内部运行了 daemon 程序和反向代理程序。daemon程序通过 K8S API 不断监控集群的变化,对 ingress 定义的规则进行解析并刷新配置到反向代理程序
Ingress 暴露服务的方式
模式1、Deployment + NodePort 的 Service 模式
1、基于 Deployment 部署 ingress-controller 并创建对应的 Service 服务(type为NodePort),将ingress暴露在集群节点ip的特定端口上
2、一般适用于宿主机ip地址相对固定不变的场景,由于 Nodeport 暴露的端口是随机端口,一般会在前面再搭建一套负载均衡器来转发请求,NodePort方式暴露 ingress 虽然简单,但多了一层NAT,在请求量级很大时对性能会有一定影响
模式2、Deployment + LoadBalancer 的 Service 模式
1、基于 Deployment 部署 ingress-controller 并创建对应的 Service 服务(type为 LoadBalancer)
2、此模式需要将 ingress 部署在公有云,大部分公有云都会为 LoadBalancer 的 service 自动创建一个负载均衡器,通常还绑定了公网地址,只要把域名解析指向该公网地址就实现了集群服务的对外暴露
模式3、DaemonSet + HostNetwork + nodeSelector 的 Service 模式【推荐】
1、基于 DaemonSet 结合 NodeSelector 来部署 ingress-controller 到特定的 node 上,再通过 HostNetwork 把该 pod 与宿主机 node 的网络打通,通过宿主机的80/433端口访问服务,此时的ingress-controller所在的node节点就类似传统架构的边缘节点(房入口的nginx服务器)
2、该方式相对NodePort模式的性能更好,缺点:由于直接利用宿主机节点的网络和端口,一个node节点只能部署一个ingress-controller,适合大并发的生产环境使用
Ingress 安装
注意:不同的暴露服务方式对应的安装方式是不一样的
安装教程
【模式3】Ingress - 部署 httpd 应用并对外访问
创建 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: dev
name: httpd
labels:
app: httpd
spec:
selector:
matchLabels:
app: httpd
matchExpressions:
- { key: app, operator: In, values: [httpd] }
replicas: 1
template:
metadata:
labels:
app: httpd
spec:
nodeName: node2
containers:
- name: httpd
image: httpd
imagePullPolicy: IfNotPresent
ports:
- name: httpd
protocol: TCP
containerPort: 80
创建 Service
apiVersion: v1
kind: Service
metadata:
namespace: dev
name: httpd
spec:
selector:
app: httpd
ports:
- protocol: TCP
port: 8080
targetPort: 80
创建 Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: dev
name: ingress-httpd-http
annotations:
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
rules:
- host: www.lixing40.com
http:
paths:
- pathType: Prefix
path: /httpd
backend:
service:
name: httpd
port:
number: 8080
创建Ingress过程中如果报如下错误:
“Error from server (InternalError): error when creating “ingress-srv.yaml”: Internal error occurred: failed calling webhook “validate.nginx.ingress.kubernetes.io”: Post “https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1/ingresses?timeout=10s”: dial tcp 10.102.20.133:443: connect: connection refused
原因:
删除nginx-ingress不彻底(没有删除ValidatingWebhookConfiguration ingress-nginx-admission),当我再次安装nginx-ingress之后,创建自定义的ingress就会报这个错误
请按照如下操作:
kubectl get ValidatingWebhookConfiguration
kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission
查看dev命名空间下的资源对象
kubectl get deployment,replicaSet,pods,service,ingress -n dev -o wide
curl 10.244.104.14
- 任意工作节点上通过Service访问httpd服务
curl 10.96.170.140:8080
查看ingress-nginx命名空间下的资源对象
kubectl get deployment,replicaSet,pods,service,ingress -n ingress-nginx -o wide
[HTTP]各节点通过域名访问httpd服务
vi /etc/hosts
192.168.111.40 www.lixing40.com
curl http://www.lixing40.com/httpd
192.168.111.40 www.lixing40.com
http://www.lixing40.com/httpd
[HTTPS]各节点通过域名访问httpd服务
对于ingress TSL的基本要求是有TSL/SSL证书,每个TLS证书都有一个过期日期,必须在证书过期前跟新证书,一般我们可以通过下面几种方法获得证书:
1、自签名的证书:用我们自己的CA(证书颁发机构)来创建和签名TLS证书。这种方法非常适合开发环境,你可以把根证书分享给团队,方便浏览器信任自签名的证书。参考这篇博客create self-signed certificate来创建你自己的证书
2、购买一个TLS证书:从浏览器和操作系统信任的知名CA(证书颁发机构)购买TLS证书
3、使用Letsencrpt证书:Letsencrpt是一家非盈利的可信证书颁发机构,他们提供免费的TLS证书
SSL是由ingress controller来处理的,而不是ingress。把TLS证书作为kubernetes sercet添加到ingress里面时,ingress controller就能获取到它,并使其变为自己的配置信息
- 创建kubernetes TLS sercet(Master1节点操作)
mkdir -p /etc/certs/ingress
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/certs/ingress/tls.key -out /etc/certs/ingress/tls.crt -subj "/CN=www.lixing40.com/O=www.lixing40.com"
kubectl create secret tls tls-ingress-httpd --key /etc/certs/ingress/tls.key --cert /etc/certs/ingress/tls.crt -n dev
kubectl get secret tls-ingress-httpd -n dev
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: dev
name: ingress-httpd-https
annotations:
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
tls:
- hosts:
- www.lixing40.com
secretName: tls-ingress-httpd
rules:
- host: www.lixing40.com
http:
paths:
- pathType: Prefix
path: /httpd
backend:
service:
name: httpd
port:
number: 8080
http://www.lixing40.com/httpd
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)