Configure advanced NGINX Ingress features - Container Service for Kubernetes

Prérequis

Vérifiez que :

Un cluster ACK managé est créé.
Le contrôleur NGINX Ingress est installé et en cours d'exécution.
kubectl est connecté au cluster.
Un Deployment et un Service sont déployés dans le cluster.

Méthodes de configuration NGINX

Le contrôleur NGINX Ingress dans ACK est entièrement compatible avec la version open source en amont. Trois méthodes sont disponibles :

Méthode	Portée	Référence
Annotation	Ingress individuel — modifiez un fichier YAML Ingress spécifique	Annotations
ConfigMap	Tous les Ingress — modifiez la ConfigMap `kube-system/nginx-configuration`	ConfigMaps
Modèle NGINX personnalisé	Contrôle total — personnalisez le modèle NGINX lorsque les autres méthodes sont insuffisantes	Modèle NGINX personnalisé

Configurer la redirection d'URL

Par défaut, le contrôleur NGINX Ingress transfère les requêtes en utilisant le chemin complet. Si votre chemin backend diffère, utilisez l'annotation nginx.ingress.kubernetes.io/rewrite-target pour le réécrire.

À partir de la version 0.22.0 du contrôleur NGINX Ingress, il est nécessaire d'utiliser des expressions régulières avec des groupes de capture dans le chemin, conjointement avec l'annotation rewrite-target .

Appliquez le modèle correspondant à la version Kubernetes de votre cluster.

Kubernetes 1.19 et versions ultérieures

cat <<-EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: foo.bar.com
  namespace: default
  annotations:
    # Rewrite the request path: strip the /svc prefix and forward the remainder to the backend.
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /svc(/|$)(.*)
        backend:
          service:
            name: web1-service
            port:
              number: 80
        pathType: ImplementationSpecific
EOF

Kubernetes 1.19 ou versions antérieures

cat <<-EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: foo.bar.com
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /svc(/|$)(.*)
        backend:
          serviceName: web1-service
          servicePort: 80
EOF

Verify the configuration:

Récupérez l'adresse IP de l'Ingress.

kubectl get ingress

Sortie attendue :

NAME           CLASS   HOSTS         ADDRESS        PORTS   AGE
foo.bar.com    nginx   foo.bar.com   172.16.XX.XX   80      46m

Envoyez une requête en utilisant l'adresse IP de l'Ingress obtenue depuis ADDRESS.
```
curl -k -H "Host: foo.bar.com" http://<ADDRESS>/svc/foo
```
Sortie attendue :
```
web1: /foo
```
Le préfixe /svc est supprimé et le backend reçoit /foo.

Configurer les règles de réécriture

L'annotation nginx.ingress.kubernetes.io/rewrite-target gère les réécritures de chemin basiques. Pour des réécritures avancées, utilisez les annotations de snippet pour injecter directement une configuration NGINX personnalisée :

Annotation	Bloc cible	Cas d'utilisation
`nginx.ingress.kubernetes.io/server-snippet`	Bloc `server {}`	Réécritures et redirections au niveau du serveur
`nginx.ingress.kubernetes.io/configuration-snippet`	Bloc `location {}`	Réécritures au niveau de l'emplacement, en-têtes personnalisés

Exemple :

annotations:
  nginx.ingress.kubernetes.io/server-snippet: |
    rewrite ^/v4/(.*)/card/query http://foo.bar.com/v5/#!/card/query permanent;
  nginx.ingress.kubernetes.io/configuration-snippet: |
    rewrite ^/v6/(.*)/card/query http://foo.bar.com/v7/#!/card/query permanent;

Vérifiez le snippet dans le fichier nginx.conf généré :

kubectl exec nginx-ingress-controller-xxxxx --namespace kube-system -- cat /etc/nginx/nginx.conf
# Replace xxxxx with the actual pod name.

Le server-snippet apparaît dans le bloc server {} et le configuration-snippet dans le bloc location {} :

# start server foo.bar.com
server {
    server_name foo.bar.com;
    listen 80;
    listen [::]:80;
    set $proxy_upstream_name "-";
    # server-snippet
    rewrite ^/v4/(.*)/card/query http://foo.bar.com/v5/#!/card/query permanent;
    ...
    # configuration-snippet
    rewrite ^/v6/(.*)/card/query http://foo.bar.com/v7/#!/card/query permanent;
    ...
}
# end server foo.bar.com

Configurez des snippets globaux avec server-snippet dans ConfigMap. Consultez la documentation du module de réécriture NGINX pour connaître la syntaxe complète de rewrite.

Configurer un certificat TLS pour Ingress

Associez un certificat TLS à un Ingress pour activer HTTPS.

Le domaine du certificat TLS doit correspondre à la valeur host de l'Ingress. Une incompatibilité empêche le contrôleur de charger le certificat.

Étape 1 : Créez le certificat et le Secret.

Générez un certificat auto-signé et une clé privée.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout tls.key -out tls.crt \
  -subj "/CN=foo.bar.com/O=foo.bar.com"

Stockez le certificat et la clé dans un Secret Kubernetes.

kubectl create secret tls tls-test-ingress --key tls.key --cert tls.crt

Étape 2 : Créez un Ingress qui référence le Secret.

Kubernetes 1.19 et versions ultérieures

cat <<EOF | kubectl create -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-test-ingress
spec:
  tls:
  - hosts:
    - foo.bar.com
    secretName: tls-test-ingress  # Reference the Secret created above.
  rules:
  - host: tls-test-ingress.com
    http:
      paths:
      - path: /foo
        backend:
          service:
            name: web1-svc
            port:
              number: 80
        pathType: ImplementationSpecific
EOF

Kubernetes 1.19 ou versions antérieures

cat <<EOF | kubectl create -f -
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-test-ingress
spec:
  tls:
  - hosts:
    - foo.bar.com
    secretName: tls-test-ingress
  rules:
  - host: tls-test-ingress.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: web1-svc
          servicePort: 80
EOF

Mettez à jour votre fichier hosts ou vos DNS pour résoudre tls-test-ingress.com vers l'IP de l'Ingress. Accédez au service via https://tls-test-ingress.com/foo.

Configurer l'authentification mutuelle TLS

Le protocole mTLS exige que le serveur et le client présentent tous deux des certificats lors de la poignée de main TLS.

Le protocole mTLS s'applique par hôte ; il n'est pas possible de définir des paramètres distincts pour différents chemins sous le même hôte.

Quatre annotations contrôlent le protocole mTLS :

Annotation	Description
`nginx.ingress.kubernetes.io/auth-tls-verify-client`	Active la vérification du certificat client. Valeurs : `"on"` (exige un certificat valide ; renvoie HTTP 400 en cas d'absence), `"optional"` (demande mais n'exige pas) ou `"off"` (désactive).
`nginx.ingress.kubernetes.io/auth-tls-secret`	Le `namespace/secretName` du Secret contenant le certificat CA pour la vérification du client.
`nginx.ingress.kubernetes.io/auth-tls-verify-depth`	La profondeur maximale de la chaîne de certificats du client. Par défaut : `1`.
`nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream`	Si la valeur est `"true"`, transmet le certificat client au backend dans un en-tête de requête.

Étape 1 : Créez une autorité de certification (CA) auto-signée.

openssl req -x509 -sha256 -newkey rsa:4096 \
  -keyout ca.key -out ca.crt \
  -days 356 -nodes \
  -subj '/CN=Fern Cert Authority'

Sortie attendue :

Generating a 4096 bit RSA private key
...
writing new private key to 'ca.key'

Étape 2 : Créez un certificat serveur.

Générez la demande de signature de certificat (CSR).

openssl req -new -newkey rsa:4096 \
  -keyout server.key -out server.csr \
  -nodes -subj '/CN=foo.bar.com'

Signez la CSR avec la CA pour produire le certificat serveur.

openssl x509 -req -sha256 -days 365 \
  -in server.csr -CA ca.crt -CAkey ca.key \
  -set_serial 01 -out server.crt

Sortie attendue :

Signature ok
subject=/CN=foo.bar.com
Getting CA Private Key

Étape 3 : Créez un certificat client.

Générez la CSR du client.

openssl req -new -newkey rsa:4096 \
  -keyout client.key -out client.csr \
  -nodes -subj '/CN=Fern'

Signez la CSR du client avec la CA.

openssl x509 -req -sha256 -days 365 \
  -in client.csr -CA ca.crt -CAkey ca.key \
  -set_serial 02 -out client.crt

Sortie attendue :

Signature ok
subject=/CN=Fern
Getting CA Private Key

Étape 4 : Vérifiez que tous les fichiers de certificat sont présents.

ls

Sortie attendue :

ca.crt  ca.key  client.crt  client.csr  client.key  server.crt  server.csr  server.key

Étape 5 : Créez des Secrets pour la CA et les certificats serveur.

kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt
kubectl create secret generic tls-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key

Étape 6 : Créez l'Ingress NGINX avec les annotations mTLS.

Kubernetes 1.19 et versions ultérieures

cat <<-EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
  name: nginx-test
  namespace: default
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          service:
            name: http-svc
            port:
              number: 80
        path: /
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - foo.bar.com
    secretName: tls-secret
EOF

Kubernetes 1.19 ou versions antérieures

cat <<-EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
  name: nginx-test
  namespace: default
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /
  tls:
  - hosts:
    - foo.bar.com
    secretName: tls-secret
EOF

Étape 7 : Créez ou mettez à jour le fichier /etc/hosts.

Récupérez l'adresse IP de l'Ingress et ajoutez-la au fichier /etc/hosts.

kubectl get ing

Sortie attendue :

NAME         HOSTS         ADDRESS        PORTS     AGE
nginx-test   foo.bar.com   39.102.XX.XX   80, 443   4h42m

echo "39.102.XX.XX  foo.bar.com" | sudo tee -a /etc/hosts

Verify the configuration:

Sans certificat client — le serveur rejette la requête :

curl --cacert ./ca.crt https://foo.bar.com

Sortie attendue :

<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx/1.19.0</center>
</body>
</html>

Avec un certificat client — la requête aboutit :
```
curl --cacert ./ca.crt --cert ./client.crt --key ./client.key https://foo.bar.com
```
Sortie attendue : la page d'accueil nginx par défaut (Welcome to nginx!).

Transférer les requêtes HTTPS vers les conteneurs backend

Par défaut, le contrôleur NGINX Ingress transfère le trafic HTTP vers les backends. Pour les backends HTTPS, ajoutez l'annotation nginx.ingress.kubernetes.io/backend-protocol: "HTTPS".

Kubernetes 1.19 et versions ultérieures

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: backend-https
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  tls:
  - hosts:
    - <your-host-name>
    secretName: <your-secret-cert-name>
  rules:
  - host: <your-host-name>
    http:
      paths:
      - path: /
        backend:
          service:
            name: <your-service-name>
            port:
              number: <your-service-port>
        pathType: ImplementationSpecific

Kubernetes 1.19 ou versions antérieures

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: backend-https
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  tls:
  - hosts:
    - <your-host-name>
    secretName: <your-secret-cert-name>
  rules:
  - host: <your-host-name>
    http:
      paths:
      - path: /
        backend:
          serviceName: <your-service-name>
          servicePort: <your-service-port>

Remplacez les espaces réservés par vos valeurs :

Espace réservé	Description
`<your-host-name>`	Votre nom de domaine
`<your-secret-cert-name>`	Le Secret contenant votre certificat TLS
`<your-service-name>`	Le nom de votre Service backend
`<your-service-port>`	Le port de votre Service backend

Utiliser des expressions régulières pour les noms de domaine

Kubernetes ne prend pas en charge nativement les expressions régulières dans les champs d'hôte Ingress. Utilisez l'annotation nginx.ingress.kubernetes.io/server-alias pour ajouter des alias de serveur basés sur des expressions régulières au fichier nginx.conf.

Étape 1 : Créez un Ingress avec un alias de serveur regex.

Cet exemple correspond à tout nom d'hôte de la forme www.<chiffres>.example.com et abc.example.com.

Kubernetes 1.19 et versions ultérieures

cat <<-EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-regex
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/server-alias: '~^www\.\d+\.example\.com$, abc.example.com'
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          service:
            name: http-svc1
            port:
              number: 80
        pathType: ImplementationSpecific
EOF

Kubernetes 1.19 ou versions antérieures

cat <<-EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-regex
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/server-alias: '~^www\.\d+\.example\.com$, abc.example.com'
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: http-svc1
          servicePort: 80
EOF

Étape 2 : Vérifiez que les alias sont actifs dans nginx.conf.

Récupérez le nom du pod du contrôleur NGINX Ingress.

kubectl get pods -n kube-system | grep nginx-ingress-controller

Sortie attendue :

nginx-ingress-controller-77cd987c4c-c****   1/1   Running   0   1h
nginx-ingress-controller-77cd987c4c-x****   1/1   Running   0   1h

Inspectez la configuration générée.

kubectl exec -n kube-system nginx-ingress-controller-77cd987c4c-c**** cat /etc/nginx/nginx.conf | grep -C3 "foo.bar.com"

Sortie attendue — la directive server_name liste tous les alias :

server {
  server_name foo.bar.com abc.example.com ~^www\.\d+\.example\.com$ ;
  listen 80  ;
  listen 443  ssl http2 ;

Étape 3 : Récupérez l'adresse IP de l'Ingress.

kubectl get ing

Sortie attendue :

NAME            HOSTS         ADDRESS        PORTS   AGE
ingress-regex   foo.bar.com   101.37.XX.XX   80      11s

Étape 4 : Testez tous les noms d'hôte correspondants.

Remplacez <IP_ADDRESS> par l'adresse obtenue à l'étape précédente.

curl -H "Host: foo.bar.com" <IP_ADDRESS>/foo        # /foo
curl -H "Host: www.123.example.com" <IP_ADDRESS>/foo # /foo
curl -H "Host: www.321.example.com" <IP_ADDRESS>/foo # /foo

Spécifier des noms de domaine génériques

Les Ingress NGINX prennent nativement en charge les noms de domaine génériques. Cet exemple correspond à tout sous-domaine de ingress-regex.com.

Étape 1 : Créez un Ingress avec un hôte générique.

Kubernetes 1.19 et versions ultérieures

cat <<-EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-regex
  namespace: default
spec:
  rules:
  - host: "*.ingress-regex.com"
    http:
      paths:
      - path: /foo
        backend:
          service:
            name: http-svc1
            port:
              number: 80
        pathType: ImplementationSpecific
EOF

Kubernetes 1.19 ou versions antérieures

cat <<-EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-regex
  namespace: default
spec:
  rules:
  - host: "*.ingress-regex.com"
    http:
      paths:
      - path: /foo
        backend:
          serviceName: http-svc1
          servicePort: 80
EOF

Étape 2 : Vérifiez server_name dans nginx.conf.

kubectl exec -n kube-system <nginx-ingress-pod-name> cat /etc/nginx/nginx.conf | grep -C3 "ingress-regex.com"

Remplacez <nginx-ingress-pod-name> par le nom réel du pod.

Sortie attendue (versions plus anciennes du contrôleur) :

# start server *.ingress-regex.com
server {
  server_name *.ingress-regex.com ;
  listen 80;
  listen [::]:80;
...
}
# end server *.ingress-regex.com

Sortie attendue (dernières versions du contrôleur) :

## start server *.ingress-regex.com
server {
  server_name ~^(?<subdomain>[\w-]+)\.ingress-regex\.com$ ;
  listen 80;
  listen [::]:80;
...
}
## end server *.ingress-regex.com

Étape 3 : Récupérez l'adresse IP de l'Ingress.

kubectl get ing

Sortie attendue :

NAME            HOSTS                 ADDRESS        PORTS   AGE
ingress-regex   *.ingress-regex.com   101.37.XX.XX   80      11s

Étape 4 : Testez la correspondance générique.

Remplacez <IP_ADDRESS> par l'adresse obtenue à l'étape précédente.

curl -H "Host: abc.ingress-regex.com" <IP_ADDRESS>/foo   # /foo
curl -H "Host: 123.ingress-regex.com" <IP_ADDRESS>/foo   # /foo
curl -H "Host: a1b1.ingress-regex.com" <IP_ADDRESS>/foo  # /foo

Utiliser des annotations pour les déploiements Canary

Les déploiements Canary acheminent un sous-ensemble du trafic vers une nouvelle version de service. Toutes les configurations Canary nécessitent nginx.ingress.kubernetes.io/canary: "true" sur l'Ingress Canary.

Ces annotations contrôlent la répartition du trafic, évaluées dans l'ordre suivant : basé sur l'en-tête → basé sur le cookie → basé sur le poids.

Annotation	Valeurs	Comportement si la condition n'est pas remplie
`nginx.ingress.kubernetes.io/canary-weight`	Entier 0–100 (pourcentage)	N/A — agit comme solution de repli finale
`nginx.ingress.kubernetes.io/canary-by-header`	Tout nom d'en-tête	Si l'en-tête est absent ou ne correspond ni à `always` ni à `never`, passe aux règles basées sur les cookies ou le poids
`nginx.ingress.kubernetes.io/canary-by-header-value`	Chaîne personnalisée (utilisée avec `canary-by-header`)	Si la valeur de l'en-tête ne correspond pas, passe à la règle suivante par ordre de priorité
`nginx.ingress.kubernetes.io/canary-by-cookie`	Nom du cookie	La valeur du cookie doit être `always` ou `never` — aucune valeur personnalisée n'est prise en charge

Déploiement Canary basé sur le poids

Achemine 20 % du trafic vers le Service Canary :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"

Déploiement Canary basé sur l'en-tête

Si l'en-tête ack a la valeur always, le trafic est acheminé vers Canary. Si la valeur est never, Canary est ignoré. Les autres valeurs passent au repli basé sur le poids (50 %) :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "50"
    nginx.ingress.kubernetes.io/canary-by-header: "ack"

Déploiement Canary basé sur l'en-tête avec une valeur d'en-tête personnalisée

Si l'en-tête ack a la valeur alibaba, le trafic est acheminé vers Canary. Les autres valeurs passent au repli basé sur le poids (20 %) :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
    nginx.ingress.kubernetes.io/canary-by-header: "ack"
    nginx.ingress.kubernetes.io/canary-by-header-value: "alibaba"

Déploiement Canary basé sur le cookie

Si aucune règle d'en-tête ne correspond et que le cookie hangzhou_region a la valeur always, le trafic est acheminé vers Canary. Les autres cas passent au repli basé sur le poids (20 %) :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
    nginx.ingress.kubernetes.io/canary-by-header: "ack"
    nginx.ingress.kubernetes.io/canary-by-header-value: "alibaba"
    nginx.ingress.kubernetes.io/canary-by-cookie: "hangzhou_region"

Les valeurs des cookies doivent être always ou never . Les valeurs personnalisées ne sont pas prises en charge.

Pour une procédure détaillée, consultez Utiliser le contrôleur NGINX Ingress pour implémenter des déploiements Canary et blue-green.

Obtenir un certificat TLS gratuit avec cert-manager

cert-manager automatise le provisionnement et le renouvellement des certificats TLS via Let's Encrypt dans Kubernetes.

Ce fichier YAML est destiné aux clusters ASK (Serverless Kubernetes). Pour les clusters ACK, consultez le guide d'installation de cert-manager .

Déployer cert-manager

kubectl apply -f https://raw.githubusercontent.com/AliyunContainerService/serverless-k8s-examples/master/cert-manager/ask-cert-manager.yaml

Vérifier que les pods cert-manager sont en cours d'exécution

kubectl get pods -n cert-manager

Sortie attendue :

NAME                     READY   STATUS    RESTARTS   AGE
cert-manager-1           1/1     Running   0          2m11s
cert-manager-cainjector  1/1     Running   0          2m11s
cert-manager-webhook     1/1     Running   0          2m10s

Créer un ClusterIssuer

cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod-http01
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <your_email_name@gmail.com>  # Replace with your email address.
    privateKeySecretRef:
      name: letsencrypt-http01
    solvers:
    - http01:
        ingress:
          class: nginx
EOF

Confirmer que ClusterIssuer est prêt

kubectl get clusterissuer

Sortie attendue :

NAME                         READY   AGE
letsencrypt-prod-http01      True    17s

Créer un Ingress qui demande un certificat

Le nom de domaine doit respecter les conditions suivantes :

Pas plus de 64 caractères
Ne doit pas être un nom de domaine générique
Accessible publiquement via HTTP (requis pour le défi ACME HTTP-01)

Kubernetes 1.19 et versions ultérieures

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-tls
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod-http01"
spec:
  tls:
  - hosts:
    - <your_domain_name>       # Replace with your domain name.
    secretName: ingress-tls
  rules:
  - host: <your_domain_name>   # Replace with your domain name.
    http:
      paths:
      - path: /
        backend:
          service:
            name: <your_service_name>   # Replace with your Service name.
            port:
              number: <your_service_port>  # Replace with your Service port.
        pathType: ImplementationSpecific
EOF

Kubernetes 1.19 ou versions antérieures

cat <<EOF | kubectl apply -f -
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-tls
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod-http01"
spec:
  tls:
  - hosts:
    - <your_domain_name>
    secretName: ingress-tls
  rules:
  - host: <your_domain_name>
    http:
      paths:
      - path: /
        backend:
          serviceName: <your_service_name>
          servicePort: <your_service_port>
EOF

Surveiller la délivrance du certificat

kubectl get cert

Sortie attendue (la délivrance peut prendre quelques minutes) :

NAME          READY   SECRET        AGE
ingress-tls   True    ingress-tls   52m

Si READY n'est pas True, inspectez le certificat pour obtenir des détails :

kubectl describe cert ingress-tls

Recherchez une section Events similaire à :

Events:
  Type    Reason     Age    From          Message
  ----    ------     ---    ----          -------
  Normal  Requested  64s    cert-manager  Created new CertificateRequest resource "ingress-tls-xxxxx"
  Normal  Issuing    40s    cert-manager  The certificate has been successfully issued

Vérifier le Secret du certificat

kubectl get secret ingress-tls

Sortie attendue :

NAME          TYPE                DATA   AGE
ingress-tls   kubernetes.io/tls   2      2m

Accédez à https://<your_domain_name> pour confirmer que HTTPS est actif.

Container Service for Kubernetes:Configure advanced NGINX Ingress features

Prérequis

Méthodes de configuration NGINX

Configurer la redirection d'URL

Configurer les règles de réécriture

Configurer un certificat TLS pour Ingress

Configurer l'authentification mutuelle TLS

Transférer les requêtes HTTPS vers les conteneurs backend

Utiliser des expressions régulières pour les noms de domaine

Spécifier des noms de domaine génériques

Utiliser des annotations pour les déploiements Canary

Obtenir un certificat TLS gratuit avec cert-manager

Déployer cert-manager

Vérifier que les pods cert-manager sont en cours d'exécution

Créer un ClusterIssuer

Confirmer que ClusterIssuer est prêt

Créer un Ingress qui demande un certificat

Surveiller la délivrance du certificat

Vérifier le Secret du certificat

Étapes suivantes