Сбой диспетчера сертификатов в кластере kubernetes с использованием gitlab autodevops

#ssl #kubernetes #gitlab

#ssl #kubernetes #gitlab

Вопрос:

Я использую GCP кластера kubernetes с gitlab autodevops. Конвейер запущен, установлен help triller, ingress и cert-manager area.

У меня уже есть домен «xpto.com.br «у которых уже есть сертификат ssl для всех поддоменов, но он настроен в приложениях iis, поэтому я не могу использовать этот сертификат в своих приложениях gcp. Итак, я использую lets encrypt with cert manager для генерации сертификатов в кластере k8s.

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

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

введите описание изображения здесь

Ответ №1:

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

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

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

issender.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'
  

Как только вы убедитесь, что это работает (с ПОДДЕЛЬНЫМИ промежуточными сертификатами), измените URL-адрес вашего эмитента на https://acme-v02.api.letsencrypt.org/directory чтобы вы могли создавать законные сертификаты. После внесения изменений удалите старый ПОДДЕЛЬНЫЙ секрет сертификата, чтобы его мог заменить новый.