k8s的网络优化(metallb)
MetalLB旨在通过提供与标准网络设备集成的Network LB实现来解决这种不平衡问题,从而使裸机群集上的外部服务也尽可能“正常运行”。
一、metallb部署
参考网址:官方网站
为什么使用metallb?
Kubernetes不提供网络负载均衡器的实现(LoadBalancer类型的服务)用于裸机集群。Kubernetes附带的Network LB的实现都是调用各种IaaS平台(GCP,AWS,Azure等)的粘合代码。如果您未在受支持的IaaS平台(GCP,AWS,Azure等)上运行,则LoadBalancers在创建时将无限期保持“待处理”状态。
裸机集群运营商只剩下两个较小的工具,即“ NodePort”和“ externalIPs”服务,可将用户流量引入其集群。这两个选项在生产用途上都有很大的缺点,这使裸金属集群成为Kubernetes生态系统中的二等公民。
MetalLB旨在通过提供与标准网络设备集成的Network LB实现来解决这种不平衡问题,从而使裸机群集上的外部服务也尽可能“正常运行”。
部署准备
如果您在IPVS模式下使用kube-proxy,则从Kubernetes v1.14.2开始,您必须启用严格的ARP模式。
请注意,如果您将kube-router用作服务代理,则不需要此设置,因为默认情况下它启用了严格的arp。
您可以通过在当前集群中编辑kube-proxy配置来实现:
[root@server2 ~]# kubectl edit configmap -n kube-system kube-proxy
并修改如下图内容
更新kube-proxy pod
[root@server2 ~]# kubectl get pod -n kube-system |grep kube-proxy | awk '{system("kubectl delete pod "$1" -n kube-system")}'
开始部署
[root@server2 ~]# mkdir metallb/
[root@server2 ~]# cd metallb/
[root@server2 metallb]# wget https://raw.githubusercontent.com/metallb/metallb/v0.9.5/manifests/namespace.yaml
[root@server2 metallb]# wget https://raw.githubusercontent.com/metallb/metallb/v0.9.5/manifests/metallb.yaml
[root@server2 metallb]# kubectl apply -f namespace.yaml
[root@server2 metallb]# vim metallb.yaml #查看里面需要的镜像
我们需要提前将镜像下载好,平且上传至私有仓库
[root@server1 harbor]# docker pull metallb/controller:v0.9.5
[root@server1 harbor]# docker pull metallb/speaker:v0.9.5
[root@server1 harbor]# docker tag metallb/speaker:v0.9.5 reg.westos.org/metallb/speaker:v0.9.5
[root@server1 harbor]# docker push reg.westos.org/metallb/speaker:v0.9.5
[root@server1 harbor]# docker tag metallb/controller:v0.9.5 reg.westos.org/metallb/controller:v0.9.5
[root@server1 harbor]# docker push reg.westos.org/metallb/controller:v0.9.5
注意这里我是在我的私有仓库里创建了对应名字的项目
[root@server2 metallb]# kubectl apply -f metallb.yaml
创建密钥,否则会出现报错
[root@server2 metallb]# kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
[root@server2 metallb]# kubectl -n metallb-system get secrets
[root@server2 metallb]# kubectl -n metallb-system get all
配置
定义地址池
[root@server2 metallb]# vim config.yml
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 172.25.1.100-172.25.1.200
[root@server2 metallb]# kubectl apply -f config.yml
测试
我们创建一个svc进行测试
[root@server2 metallb]# vim nginx.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
#externalIPs:
#- 172.25.2.100
#clusterIP: None
#type: NodePort
type: LoadBalancer #指定一个 LoadBalancer 类型的 Service
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: myapp:v1
我们可以看到我们部署的nginx-svc已经分配到了一个地址池中的ip
集群内部访问
集群外部访问
二、metallb+ingress
上篇博客中有对于ingress的yaml文件,可以复制过来进行修改,需要修改网络模式
[root@server2 ingress-nginx]# vim deploy.yaml
去除之前做的节点绑定
[root@server2 ingress-nginx]# kubectl apply -f deploy.yaml
[root@server2 ingress-nginx]# kubectl -n ingress-nginx get all
user -> vip(metallb) -> ingress-nginx -> svc -> pod
[root@server2 ingress-nginx]# cat nginx-svc.yml
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: myapp:v1
[root@server2 ingress-nginx]# cat demo.yml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: nginx-test
spec:
# tls:
# - hosts:
# - www1.westos.org
# secretName: tls-secret
rules:
- host: www1.westos.org
http:
paths:
- path: /
backend:
serviceName: nginx-svc
servicePort: 80
[root@server2 ingress-nginx]# kubectl apply -f nginx-svc.yml
[root@server2 ingress-nginx]# kubectl apply -f demo.yml
[root@server2 ingress-nginx]# kubectl get ingress
[root@server2 ingress-nginx]# kubectl describe ingress nginx-test
[root@server2 ingress-nginx]# kubectl get svc nginx-svc
这里需要给这个ip做好地址解析,然后在外部访问域名查看效果。
三、calico网络插件
官网:https://docs.projectcalico.org/getting-started/kubernetes/self-managed-onprem/onpremises
calico简介:
flannel实现的是网络通信,calico的特性是在pod之间的隔离。
通过BGP路由,但大规模端点的拓扑计算和收敛往往需要一定的时间和计算资源。
纯三层的转发,中间没有任何的NAT和overlay,转发效率最好。
Calico 仅依赖三层路由可达。Calico 较少的依赖性使它能适配所有 VM、Container、白盒或者混合环境场景。
准备环境
[root@server2 ~]# mkdir calico
[root@server2 ~]# cd calico/
[root@server2 calico]# ls
[root@server2 calico]# wget https://docs.projectcalico.org/manifests/calico.yaml
从yaml文件中找到所需的镜像,从官方拉取并上传到自己的私有仓库
注意此处我已经在仓库中创建的calico项目
[root@server1 harbor]# docker pull docker.io/calico/cni:v3.18.1
[root@server1 harbor]# docker tag docker.io/calico/cni:v3.18.1 reg.westos.org/calico/cni:v3.18.1
[root@server1 harbor]# docker push reg.westos.org/calico/cni:v3.18.1
[root@server1 harbor]# docker pull docker.io/calico/node:v3.18.1
[root@server1 harbor]# docker tag docker.io/calico/node:v3.18.1 reg.westos.org/calico/node:v3.18.1
[root@server1 harbor]# docker push reg.westos.org/calico/node:v3.18.1
[root@server1 harbor]# docker pull docker.io/calico/pod2daemon-flexvol:v3.18.1
[root@server1 harbor]# docker tag docker.io/calico/pod2daemon-flexvol:v3.18.1 reg.westos.org/calico/pod2daemon-flexvol:v3.18.1
[root@server1 harbor]# docker push reg.westos.org/calico/pod2daemon-flexvol:v3.18.1
[root@server1 harbor]# docker pull docker.io/calico/kube-controllers:v3.18.1
[root@server1 harbor]# docker tag docker.io/calico/kube-controllers:v3.18.1 reg.westos.org/calico/kube-controllers:v3.18.1
[root@server1 harbor]# docker push reg.westos.org/calico/kube-controllers:v3.18.1
最后将yaml文件中的image地址改成如图所示:
此处将IPIP模式关闭
之前安装的flannel插件,需保持一致;如果没有安装过flannel,则不需要管
先将之前flannel网络组件删除
[root@server2 ~]# kubectl delete -f kube-flannel.yml
安装插件
所有节点都需要进行以下两步操作
[root@server2 calico]# cd /etc/cni/net.d/
[root@server2 net.d]# mv 10-flannel.conflist /mnt
[root@server2 calico]# kubectl apply -f calico.yaml
[root@server2 calico]# kubectl -n kube-system get pod
calico网络架构
Felix:监听ECTD中心的存储获取事件,用户创建pod后,Felix负责将其网卡、IP、MAC都设置好,然后在内核的路由表里面写一条,注明这个IP应该到这张网卡。同样如果用户制定了隔离策略,Felix同样会将该策略创建到ACL中,以实现隔离。
BIRD:一个标准的路由程序,它会从内核里面获取哪一些IP的路由发生了变化,然后通过标准BGP的路由协议扩散到整个其他的宿主机上,让外界都知道这个IP在这里,路由的时候到这里来。
IPIP工作模式:适用于互相访问的pod不在同一个网段中,跨网段访问的场景。
BGP工作模式:适用于互相访问的pod在同一个网段,适用于大型网络。
网络策略
NetworkPolicy策略模型:控制某个namespace下的pod的网络出入站规则
官网:https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/
限制访问指定服务:
# vim nginx-policy.yml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-nginx
spec:
podSelector:
matchLabels:
app: nginx
更多推荐
所有评论(0)