Блог

Я хочу знать, существует ли управление версиями для конфигурации входа, аналогичное тому, что мы имеем в развертываниях. Предположим, что есть неправильная конфигурация, которую я хотел бы вернуть к предыдущей конфигурации. Я хотел бы разобраться generation в конфигурации ingress YAML.

 apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/service-match: 'new-nginx: header("foo", /^bar$/)'           #Canary release rule. In this example, the request header is used.
    nginx.ingress.kubernetes.io/service-weight: 'new-nginx: 50,old-nginx: 50'                #The route weight.
  creationTimestamp: null
  generation: 1
  name: nginx-ingress
  selfLink: /apis/extensions/v1beta1/namespaces/default/ingresses/nginx-ingress
spec:
  rules:                                                        ##The Ingress rule.
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: new-nginx
          servicePort: 80
        path: /
      - backend:
          serviceName: old-nginx
          servicePort: 80
        path: /
 

Kubernetes не предлагает этого изначально, как и инструмент управления, такой как Rancher.

Если вы хотите это сделать, вам нужен инструмент infra-as-code, такой как Terreform, ansible и т. Д. Файлы конфигурации для них могут быть версионированы в репозитории.

Даже без них вы можете самостоятельно экспортировать give ingress yaml и зафиксировать его в репозитории.

Немного другой способ взглянуть на решение — вы могли бы использовать GitOps. Я имею в виду, что вы могли бы поместить все свои yaml в репозиторий git, установить ArgoCD в свой кластер, а затем просто позволить ArgoCD выполнить синхронизацию за вас. В тот момент, когда вы поняли, что что-то перепутали в файле yaml, просто отмените фиксацию в репозитории git. Таким образом, вы сохраняете историю и получаете изящное решение, не основанное на мнении.