我们经常谈论托管Kubernetes
或在云中运行的Kubernetes
,但我们也在非云的环境(例如VMware
或裸机服务器)上运行Kubernetes
。
您可能还会听到很多有关云供应商集成的经典案例:您可以获取无密码凭据来访问托管服务,无需手动干预即可配置云负载均衡器,自动创建DNS
条目等。
在本地运行时,通常无法使用这些集成功能,除非您使用的是受支持的云平台(如 OpenStack
)。那么当在裸机或VM
上运行时,如何获得Cloud Native
环境的自动化优势?
所以让我们一步一步去看我们所想实现的功能。
本文中使用的所有清单均可在github
项目中(https://github.com/clusterfrak-dynamics/gitops-template)获取。
GitOps
与往常一样,我们使用GitOps
和FluxCD
将我们的资源部署到集群中,无论它们是在云上还是在本地。你可以参考跟多我们关于Flux的文章。
首先,您可以使用我们的GitOps
模板,并根据需要对其进行自定义。kubectl
如果更合适,您也可以直接部署清单 。
以下让我们深入研究我们的组件。
负载均衡
在云上运行kubernetns时,通常可以立即使用Load Balancer
。在裸机或VM
上运行时,负载均衡器保持pending
不可用状态。
因此,首先,我们希望我们的服务类型LoadBalancer
不处于pending
不可用状态,并且能够在需要时提供动态负载平衡器,而无需手动配置haproxy
或其他类似的服务。
metallb
可以提供两种模式的虚拟负载均衡器的实现:
BGP
协议ARP
后者更简单,因为它可以在几乎任何二层网络上工作,而无需进一步配置。
在ARP
模式下,metallb
的配置非常简单。您只需要给它提供一些可以使用的IP
就可以了。
配置清单可在此处或官方文件中找到。要配置所需的IP地址,可以使用ConfigMap
完成。
metallb-config.yaml
:
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 10.10.39.200-10.10.39.220
您还需要生成一个密钥来加密Metallb
组件通信,您可以使用以下脚本来生成Kubernetes secret yaml
:
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)" -o yaml --dry-run=client > metallb-secret.yaml
部署完所有内容后,您应该在metallb-system
namespace
内看到相应的pods
:
NAME READY STATUS RESTARTS AGE
controller-57f648cb96-tvr9q 1/1 Running 0 2d1h
speaker-7rd8p 1/1 Running 0 2d1h
speaker-7t7rg 1/1 Running 0 2d1h
speaker-8qm2t 1/1 Running 0 2d1h
speaker-bks4s 1/1 Running 0 2d1h
speaker-cz6bc 1/1 Running 0 2d1h
speaker-h8b54 1/1 Running 0 2d1h
speaker-j6bss 1/1 Running 0 2d1h
speaker-phvv7 1/1 Running 0 2d1h
speaker-wdwjc 1/1 Running 0 2d1h
speaker-xj25p 1/1 Running 0 2d1h
现在,我们准备测试负载均衡器。为此,我们直接进入下一个主题。
Ingress controller
在云上运行时,除了经典的4层负载均衡器以外,您有时还可以在GCP
和AWS
上获得7层负载均衡器(例如,应用程序负载均衡器)。但是它们的功能有限,而且成本效益不高,而且您经常需要一个ingress controller
来管理来自Kubernetes
集群的流量。
这个ingress controller
通常通过服务类型为LoadBalancer
在外部发布。这就是为什么我们以前的metallb
部署会派上用场。
第一个也是最常用的ingress controller
之一是nginx-ingress
,它可以轻松地与Helm
一起部署。
由于我们将Flux
与Helm Operator
结合使用,因此根据我们使用的Helm
,您可以参考以下values.yaml
配置:
因为我们将Flux
与Helm Operator
结合使用,所以我们使用了一个Helm Release
的版本,您可以从中得到values.yaml
,以下展示了我们的配置:
apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
name: nginx-ingress
namespace: nginx-ingress
spec:
releaseName: nginx-ingress
chart:
repository: https://kubernetes-charts.storage.googleapis.com
version: 1.36.3
name: nginx-ingress
values:
controller:
publishService:
enabled: true
kind: "DaemonSet"
service:
enabled: true
externalTrafficPolicy: Local
daemonset:
hostPorts:
http: 80
https: 443
defaultBackend:
replicaCount: 2
podSecurityPolicy:
enabled: true