Диспетчер сертификатов не работает в кластере kubernetes с помощью gitlab autodevops

Question

Я использую кластер kubernetes GCP с gitlab autodevops.Трубопровод работает, установлен триллер помощи, вход и область диспетчера сертификатов.

У меня уже есть домен "xpto.com.br", в котором уже есть сертификат ssl для всех поддоменов, но он настроен на приложения iis, поэтому я не могу использовать этот сертификат в своих приложениях gcp.Поэтому я использую позволяет шифровать с помощью диспетчера сертификатов для создания сертификатов в кластере k8s.

Все настроено, но мои приложения не отвечают с использованием https.Веб-браузер показывает «backend 404», если я пытаюсь заставить «https» запускать приложения.

После некоторых попыток я решил удалить cert-manager из кластера, чтобы повторить попытку установки.Но gitlab не позволяет снова установить менеджер сертификатов, как показано на рисунке ниже:

Answer 1

GitLab не предоставляет опцию uninstall, поэтому вам придется либо вручную переустановить cert-manager в gitlab-managed-apps, либо повторно присоединить ваш кластер к вашему проекту GitLab. Если вы хотите сделать это вручную, запустите:

helm install \
    --name cert-manager \
    --namespace gitlab-managed-apps \
    stable/cert-manager

Это относится только к части менеджера сертификатов. Еще одна вещь, которую стоит отметить, - то, что cert-manager чудесным образом не распознает вашу потребность в сертификате и не создает его. Вам нужно будет создать необходимые ресурсы, такие как вход, clusterIssuer и ресурс сертификата. Также следует отметить, что вы можете использовать один подстановочный сертификат tls для всех ваших поддоменов. Не создавайте избыточных сертификатов, это повлияет на вашу квоту. Попробуйте использовать следующий простой шаблон (например, если вы используете route53 для вашего провайдера DNS):

issuer.yaml

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
  namespace: default
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: <your email>
    privateKeySecretRef:
      name: letsencrypt-staging
    dns01:
      providers:
      - name: route53
        route53:
          region: us-east-1
          accessKeyID: <access key id>
          secretAccessKeySecretRef:
            name: <secret name>
            key: secret-access-key

ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: <ingress name>
  annotations:
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
    certmanager.k8s.io/cluster-issuer: letsencrypt-staging
spec:
  tls:
  - hosts:
    - "*.example.com"
    secretName: cert-wildcard-secret
  rules:
  - host: "sub.example.com"
    http:
      paths:
      - path: /
        backend:
          serviceName: <service name>
          servicePort: <port number>

certificate.yaml

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: cert-wildcard
spec:
  secretName: cert-wildcard-secret
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer
  dnsNames:
  - '*.example.com'
  acme:
    config:
    - dns01:
        provider: route53
      domains:
      - '*.example.com'

После того, как вы убедились, что это работает (с промежуточными сертификатами FAKE), измените URL-адрес вашего эмитента на https://acme -staging-v02.api.letsencrypt.org / directory , чтобы вы могли создать законные сертификаты. После внесения изменений удалите старый секрет сертификата FAKE, чтобы новый мог заменить его.