本文共 6807 字，大约阅读时间需要 22 分钟。

一、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.ymlapiVersion: v1kind: ConfigMapmetadata:  namespace: metallb-system  name: configdata:  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: v1kind: Servicemetadata:  name: nginx-svcspec:  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/v1kind: Deploymentmetadata:  name: demospec:  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: v1kind: Servicemetadata:  name: nginx-svcspec:  selector:    app: nginx  ports:  - protocol: TCP    port: 80    targetPort: 80  type: LoadBalancer---apiVersion: apps/v1kind: Deploymentmetadata:  name: deploymentspec:  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/v1beta1kind: Ingressmetadata:  name: nginx-testspec: # 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.ymlapiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:  name: deny-nginxspec:  podSelector:    matchLabels:      app: nginx

转载地址：http://ehjxi.baihongyu.com/