验证Kubernetes配置的方法


Methods of Verifying Kubernetes Configuration

我一直在做一个小型项目，尝试学习Kubernetes。我有一个相对简单的群集，其中包含两个服务(一个入口)，现在正在添加Redis数据库。我将这个集群托管在Google Kubernetes Engine(GKE)中，但是使用Minikube在本地运行该集群并尝试所有操作，然后再提交任何更改并将其推送到GKE的产品环境中。

在此项目中，我注意到GKE在配置方式和Minikube中的工作方式上似乎有些许差异。我以前在入口中已经看到了这一点，现在在持久卷中已经看到了这一点。

例如，要在GKE中使用持久卷运行Redis，我可以使用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
apiVersion: apps/v1
kind: Deployment
metadata:
  name: chatter-db-deployment
  labels:
    app: chatter
spec:
  replicas: 1
  selector:
    matchLabels:
      app: chatter-db-service
  template:
    metadata:
      labels:
        app: chatter-db-service
    spec:
      containers:
      - name: master
        image: redis
        args: [
         "--save","3600","1","300","100","60","10000",
         "--appendonly","yes",
        ]
        ports:
        - containerPort: 6379
        volumeMounts:
        - name: chatter-db-storage
          mountPath: /data/
      volumes:
      - name: chatter-db-storage
        gcePersistentDisk:
          pdName: chatter-db-disk
          fsType: ext4

最后的gcePersistentDisk部分指的是我使用gcloud compute disks create创建的磁盘。但是，这在Minikube中根本行不通，因为我无法以这种方式创建磁盘。

相反，我需要使用：

1
2
3
4
      volumes:
      - name: chatter-db-storage
        persistentVolumeClaim:
          claimName: chatter-db-claim

我还需要为PeristentVolume和PersistentVolumeClaim包括单独的配置。

我可以轻松地在Minikube或GKE中使某些东西正常工作，但是我不确定获得同时适用于两者的配置的最佳方法是什么。理想情况下，我希望有一个用于部署此应用程序的k8s.yaml文件，并且kubectl apply -f k8s.yaml应该在两种环境下都可以工作，从而允许我在Minikube上进行本地测试，然后在满意时推送到GKE。

我知道这两种环境之间存在差异，并且可能会在某种程度上泄漏到配置中，但是在推出之前必须有一种有效的方法来验证配置吗？测试配置的最佳实践是什么？我的问题主要归结为：

  • 拥有一个可以同时适用于GKE和Minikube的Kubernetes配置是否可行？
  • 如果不是，拥有一个几乎共享的Kubernetes配置是否可行，该配置将覆盖GKE和Minikube的特定部分？
  • 现有项目如何解决这个特定问题？
  • 最好的方法是在GKE中简单地创建一个单独的dev集群并对其进行测试，而不是完全不理会Minikube吗？

    • 是的，您发现Kubernetes配置的某些部分从一开始就并不完美。但是有更新的解决方案。

    存储抽象

    Kubernetes较新版本中的想法是，您的应用程序配置是带有卷的部署，该部署指的是StorageClass的PersistentVolumeClaim。

    StorageClass和PersistentVolume属于基础结构配置。

    有关如何为Minikube配置持久卷，请参阅配置Pod以使用PersistentVolume进行存储。对于GKE，您可以使用GCEPersistentDisk配置一个持久卷，或者如果您要将应用程序部署到AWS，则可以将持久卷用于AWSElasticBlockStore。

    入口和服务抽象

    类型为LoadBalancer的

    Service和NodePort与Ingress结合使用时，在云提供商和Ingress Controller之间的工作方式不同。此外，Istio之类的Services Mesh实现还引入了VirtualService。按照我的理解，计划是使用Ingress v2改善这种情况。

    相关讨论