k8s的网络优化(metallb)

一、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

转载至https://blog.csdn.net/Sun__s/article/details/114370460