Vytvoření kontroleru příchozího přenosu dat protokolu HTTPS a použití vlastních certifikátů TLS ve službě Azure Kubernetes Service (AKS)

Kontroler příchozích dat je software, který poskytuje reverzní proxy server, konfigurovatelné směrování provozu a ukončení protokolu TLS pro služby Kubernetes. Prostředky příchozího přenosu dat Kubernetes se používají ke konfiguraci pravidel příchozího přenosu dat a tras pro jednotlivé služby Kubernetes. Pomocí kontroleru příchozího přenosu dat a pravidel příchozího přenosu dat je možné jednu IP adresu použít ke směrování provozu do několika služeb v clusteru Kubernetes.

Tento článek ukazuje, jak nasadit kontroler příchozího přenosu dat NGINX v clusteru Azure Kubernetes Service (AKS). Vygenerování vlastních certifikátů a vytvoření tajného kódu Kubernetes pro použití s trasou příchozího přenosu dat. Nakonec se v clusteru AKS spustí dvě aplikace, z nichž každá je přístupná přes jednu IP adresu.

Můžete také:

Než začnete

Tento článek používá Helm 3 k instalaci kontroleru příchozího přenosu dat NGINX na [podporovanou verzi Kubernetes][verze podporované pomocí AKS]. Ujistěte se, že používáte nejnovější verzi Helmu a že máte přístup k úložišti Helm ingress-nginx. Kroky popsané v tomto článku nemusí být kompatibilní s předchozími verzemi chartu Helm, kontroleru příchozího přenosu dat NGINX nebo Kubernetes.

Další informace o konfiguraci a používání Nástroje Helm najdete v tématu Instalace aplikací pomocí nástroje Helm v Azure Kubernetes Service (AKS).

Tento článek také vyžaduje použití Azure CLI verze 2.0.64 nebo novější. Verzi zjistíte spuštěním příkazu az --version. Pokud potřebujete instalaci nebo upgrade, přečtěte si téma Instalace Azure CLI.

Kromě toho tento článek předpokládá, že máte existující cluster AKS s integrovaným ACR. Další podrobnosti o vytvoření clusteru AKS s integrovaným ACR najdete v tématu Ověřování pomocí Azure Container Registry z Azure Kubernetes Service.

Import imagí používaných chartem Helm do ACR

Tento článek používá chart Helm kontroleru příchozího přenosu dat NGINX,který spoléhá na tři image kontejneru. Pomocí az acr import naimportujte tyto image do ACR.

REGISTRY_NAME=<REGISTRY_NAME>
SOURCE_REGISTRY=k8s.gcr.io
CONTROLLER_IMAGE=ingress-nginx/controller
CONTROLLER_TAG=v1.0.4
PATCH_IMAGE=ingress-nginx/kube-webhook-certgen
PATCH_TAG=v1.1.1
DEFAULTBACKEND_IMAGE=defaultbackend-amd64
DEFAULTBACKEND_TAG=1.5

az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$CONTROLLER_IMAGE:$CONTROLLER_TAG --image $CONTROLLER_IMAGE:$CONTROLLER_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$PATCH_IMAGE:$PATCH_TAG --image $PATCH_IMAGE:$PATCH_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG --image $DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG

Poznámka

Kromě importu imagí kontejnerů do ACR můžete do ACR importovat také grafy Helm. Další informace najdete v tématu Nabízení a stažení grafů Helm do registru kontejneru Azure.

Vytvoření kontroleru příchozího přenosu dat

K vytvoření kontroleru příchozího přenosu dat použijte Helm k instalaci nginx-ingress. Pro přidání redundance se nasadí dvě repliky kontrolerů příchozího přenosu dat NGINX s parametrem --set controller.replicaCount. Pokud chcete plně využít výhod spouštění replik kontroleru příchozího přenosu dat, ujistěte se, že je v clusteru AKS více než jeden uzel.

Kontroler příchozího přenosu dat je potřeba naplánovat také v uzlu Linuxu. V uzlech Windows Serveru by se kontroler příchozího přenosu dat neměl spouštět. Selektor uzlů se specifikuje pomocí parametru --set nodeSelector, aby plánovači Kubernetes oznámil, že má spustit kontroler příchozího přenosu dat NGINX v uzlu Linuxu.

Tip

Následující příklad vytvoří obor názvů Kubernetes pro prostředky příchozího přenosu dat s názvem ingress-basic a je určený k práci v tomto oboru názvů. Podle potřeby zadejte obor názvů pro vlastní prostředí. Pokud váš cluster AKS nemá povolenou službu Kubernetes RBAC, přidejte --set rbac.create=false do příkazů Helmu .

Tip

Pokud chcete pro požadavky na kontejnery v clusteru povolit zachování zdrojové IP adresy klienta, přidejte do příkazu Helm --set controller.service.externalTrafficPolicy=Local install . Zdrojová IP adresa klienta je uložená v hlavičce požadavku v části X-Forwarded-For. Při použití kontroleru příchozího přenosu dat s povolenou zachováním zdrojové IP adresy klienta nebude průchod TLS fungovat.

# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

# Set variable for ACR location to use for pulling images
ACR_URL=<REGISTRY_URL>

# Use Helm to deploy an NGINX ingress controller
helm install nginx-ingress ingress-nginx/ingress-nginx \
    --namespace ingress-basic --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_URL \
    --set controller.image.image=$CONTROLLER_IMAGE \
    --set controller.image.tag=$CONTROLLER_TAG \
    --set controller.image.digest="" \
    --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.admissionWebhooks.patch.image.registry=$ACR_URL \
    --set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
    --set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
    --set controller.admissionWebhooks.patch.image.digest="" \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set defaultBackend.image.registry=$ACR_URL \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest=""

Během instalace se vytvoří veřejná IP adresa Azure pro kontroler příchozího přenosu dat. Tato veřejná IP adresa je statická po dobu životnosti kontroleru příchozího přenosu dat. Pokud odstraníte kontroler příchozího přenosu dat, přiřazení veřejné IP adresy se ztratí. Pokud pak vytvoříte další kontroler příchozího přenosu dat, přiřadí se nová veřejná IP adresa. Pokud chcete zachovat použití veřejné IP adresy, můžete místo toho vytvořit kontroler příchozího přenosu dat se statickou veřejnou IP adresou.

Veřejnou IP adresu získáte pomocí kubectl get service příkazu .

kubectl --namespace ingress-basic get services -o wide -w nginx-ingress-ingress-nginx-controller

Přiřazení IP adresy ke službě trvá několik minut.

$ kubectl --namespace ingress-basic get services -o wide -w nginx-ingress-ingress-nginx-controller

NAME                                     TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE   SELECTOR
nginx-ingress-ingress-nginx-controller   LoadBalancer   10.0.74.133   EXTERNAL_IP     80:32486/TCP,443:30953/TCP   44s   app.kubernetes.io/component=controller,app.kubernetes.io/instance=nginx-ingress,app.kubernetes.io/name=ingress-nginx

Poznamenejte si tuto veřejnou IP adresu, protože se používá v posledním kroku k otestování nasazení.

Zatím nebyla vytvořena žádná pravidla příchozího přenosu dat. Pokud vyhledáte veřejnou IP adresu, zobrazí se výchozí stránka 404 kontroleru příchozího přenosu dat NGINX.

Generování certifikátů TLS

Pro tento článek vygeneruje certifikát podepsaný svým držitelem pomocí openssl . V případě použití v produkčním prostředí byste měli požádat o důvěryhodný podepsaný certifikát prostřednictvím poskytovatele nebo vlastní certifikační autority (CA). V dalším kroku vygeneruje tajný kód Kubernetes pomocí certifikátu TLS a privátního klíče vygenerované protokolem OpenSSL.

Následující příklad vygeneruje 2048bitový certifikát RSA X509 platný po dobu 365 dnů s názvem aks-ingress-tls.crt. Soubor privátního klíče má název aks-ingress-tls.key. Tajný kód PROTOKOLU TLS Kubernetes vyžaduje oba tyto soubory.

Tento článek funguje demo.azure.com běžným názvem subjektu a není nutné ho měnit. Pro použití v produkčním prostředí zadejte pro parametr vlastní hodnoty -subj organizace:

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

Vytvoření tajného klíče Kubernetes pro certifikát TLS

Pokud chcete Kubernetes povolit použití certifikátu TLS a privátního klíče pro kontroler příchozího přenosu dat, vytvoříte a použijete tajný kód. Tajný kód se definuje jednou a použije soubor certifikátu a klíče vytvořený v předchozím kroku. Na tento tajný kód se pak odkazujete při definování tras příchozího přenosu dat.

Následující příklad vytvoří název tajného kódu aks-ingress-tls:

kubectl create secret tls aks-ingress-tls \
    --namespace ingress-basic \
    --key aks-ingress-tls.key \
    --cert aks-ingress-tls.crt

Spouštění ukázkových aplikací

Nakonfigurovali jste kontroler příchozího přenosu dat a tajný kód s vaším certifikátem. Teď v clusteru AKS spustíme dvě ukázkové aplikace. V tomto příkladu se Helm používá k nasazení dvou instancí jednoduché aplikace Hello World.

Pokud chcete zobrazit kontroler příchozího přenosu dat v akci, spusťte v clusteru AKS dvě ukázkové aplikace. V tomto příkladu použijete k nasazení dvou instancí jednoduché kubectl apply aplikace Hello World.

Vytvořte soubor aks-helloworld.yaml a zkopírujte ho v následujícím příkladu YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-helloworld
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-helloworld
  template:
    metadata:
      labels:
        app: aks-helloworld
    spec:
      containers:
      - name: aks-helloworld
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        env:
        - name: TITLE
          value: "Welcome to Azure Kubernetes Service (AKS)"
---
apiVersion: v1
kind: Service
metadata:
  name: aks-helloworld
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: aks-helloworld

Vytvořte soubor ingress-demo.yaml a zkopírujte ho v následujícím příkladu YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ingress-demo
  template:
    metadata:
      labels:
        app: ingress-demo
    spec:
      containers:
      - name: ingress-demo
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        env:
        - name: TITLE
          value: "AKS Ingress Demo"
---
apiVersion: v1
kind: Service
metadata:
  name: ingress-demo
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: ingress-demo

Spusťte dvě ukázkové aplikace pomocí kubectl apply příkazu :

kubectl apply -f aks-helloworld.yaml --namespace ingress-basic
kubectl apply -f ingress-demo.yaml --namespace ingress-basic

Vytvoření trasy příchozího přenosu dat

Obě aplikace teď běží v clusteru Kubernetes, ale jsou nakonfigurované se službou typu ClusterIP . Aplikace proto nejsou přístupné z internetu. Pokud je chcete veřejně používat, vytvořte prostředek příchozího přenosu dat Kubernetes. Prostředek příchozího přenosu dat nakonfiguruje pravidla, která směruje provoz do jedné ze dvou aplikací.

V následujícím příkladu se provoz na adresu https://demo.azure.com/ směruje do služby s názvem aks-helloworld . Provoz na adresu https://demo.azure.com/hello-world-two se směruje do ingress-demo služby. Pro tento článek nemusíte měnit tyto ukázkové názvy hostitelů. Pro produkční použití zadejte názvy zadané jako součást žádosti o certifikát a procesu generování.

Tip

Pokud se název hostitele zadaný během procesu žádosti o certifikát( název cn) neshoduje s hostitelem definovaným ve vaší trase příchozího přenosu dat, řadič příchozího přenosu dat zobrazí upozornění Napodobenin kontroleru příchozího přenosu dat Kubernetes. Ujistěte se, že se názvy hostitelů tras příchozího přenosu dat a certifikátu shodují.

Část tls sděluje trasu příchozího přenosu dat, aby pro hostitelskou trasu s názvem aks-ingress-tls demo.azure.com. Opět pro produkční použití zadejte vlastní adresu hostitele.

Vytvořte soubor s názvem a hello-world-ingress.yaml zkopírujte ho v následujícím příkladu YAML.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-ingress
  namespace: ingress-basic
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  tls:
  - hosts:
    - demo.azure.com
    secretName: aks-ingress-tls
  rules:
  - host: demo.azure.com
    http:
      paths:
      - path: /hello-world-one(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld
            port:
              number: 80
      - path: /hello-world-two(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: ingress-demo
            port:
              number: 80
      - path: /(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld
            port:
              number: 80

Pomocí příkazu vytvořte prostředek příchozího kubectl apply -f hello-world-ingress.yaml přenosu dat.

kubectl apply -f hello-world-ingress.yaml

Příklad výstupu ukazuje vytvoření prostředku příchozího přenosu dat.

$ kubectl apply -f hello-world-ingress.yaml

ingress.extensions/hello-world-ingress created

Testování konfigurace příchozího přenosu dat

K otestování certifikátů pomocí našeho demo.azure.com hostitele použijte a curl zadejte parametr --resolve. Tento parametr umožňuje mapovat název demo.azure.com na veřejnou IP adresu kontroleru příchozího přenosu dat. Zadejte veřejnou IP adresu vlastního kontroleru příchozího přenosu dat, jak je znázorněno v následujícím příkladu:

curl -v -k --resolve demo.azure.com:443:EXTERNAL_IP https://demo.azure.com

S adresou nebyla poskytnuta žádná další cesta, takže kontroler příchozího přenosu dat ve výchozím nastavení / směruje. Vrátí se první ukázková aplikace, jak je znázorněno v následujícím zhuštěném ukázkovém výstupu:

$ curl -v -k --resolve demo.azure.com:443:EXTERNAL_IP https://demo.azure.com

[...]
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <link rel="stylesheet" type="text/css" href="/static/default.css">
    <title>Welcome to Azure Kubernetes Service (AKS)</title>
[...]

Parametr -v v našem curl příkazu vypište podrobné informace, včetně přijatého certifikátu TLS. V polovině výstupu curl můžete ověřit, že se použil váš vlastní certifikát TLS. Parametr -k pokračuje v načítání stránky, i když používáme certifikát podepsaný svým držitelem. Následující příklad ukazuje, že Vystavitel: CN = demo. Azure. com; O = AKS- příchozí certifikát TLS byl použit:

[...]
* Server certificate:
*  subject: CN=demo.azure.com; O=aks-ingress-tls
*  start date: Oct 22 22:13:54 2018 GMT
*  expire date: Oct 22 22:13:54 2019 GMT
*  issuer: CN=demo.azure.com; O=aks-ingress-tls
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
[...]

Nyní přidejte cestu /Hello-World-Two k adrese, například https://demo.azure.com/hello-world-two . Vrátí se druhá ukázková aplikace s vlastním názvem, jak je znázorněno v následujícím zhuštěném příkladu výstupu:

$ curl -v -k --resolve demo.azure.com:443:EXTERNAL_IP https://demo.azure.com/hello-world-two

[...]
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <link rel="stylesheet" type="text/css" href="/static/default.css">
    <title>AKS Ingress Demo</title>
[...]

Vyčištění prostředků

Tento článek používá Helm k instalaci komponent příchozího přenosu dat a ukázkových aplikací. Když nasadíte graf Helm, vytvoří se několik prostředků Kubernetes. Mezi tyto prostředky patří lusky, nasazení a služby. Chcete-li vyčistit tyto prostředky, můžete buď odstranit celý vzorový obor názvů, nebo jednotlivé prostředky.

Odstranění ukázkového oboru názvů a všech prostředků

Chcete-li odstranit celý vzorový obor názvů, použijte kubectl delete příkaz a zadejte název oboru názvů. Všechny prostředky v oboru názvů jsou odstraněny.

kubectl delete namespace ingress-basic

Odstranit prostředky jednotlivě

Další možností je podrobnější přístup k odstranění jednotlivých vytvořených prostředků. Seznam vydaných verzí Helm pomocí helm list příkazu.

helm list --namespace ingress-basic

Vyhledejte graf s názvem Nginx- příchozí, jak je znázorněno v následujícím příkladu výstupu:

$ helm list --namespace ingress-basic

NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
nginx-ingress           ingress-basic   1               2020-01-06 19:55:46.358275 -0600 CST    deployed        nginx-ingress-1.27.1    0.26.1 

Odinstalujte verze pomocí helm uninstall příkazu.

helm uninstall nginx-ingress --namespace ingress-basic

Následující příklad odinstaluje nasazení NGINX příchozího přenosu dat.

$ helm uninstall nginx-ingress --namespace ingress-basic

release "nginx-ingress" uninstalled

Dále odeberte dvě ukázkové aplikace:

kubectl delete -f aks-helloworld.yaml --namespace ingress-basic
kubectl delete -f ingress-demo.yaml --namespace ingress-basic

Odebrat trasu příchozího přenosu dat směrovaného do ukázkových aplikací:

kubectl delete -f hello-world-ingress.yaml

Odstraňte tajný klíč certifikátu:

kubectl delete secret aks-ingress-tls --namespace ingress-basic

Nakonec můžete odstranit samotný obor názvů. Použijte kubectl delete příkaz a zadejte název vašeho oboru názvů:

kubectl delete namespace ingress-basic

Další kroky

Tento článek obsahuje některé externí komponenty, které se AKS. Další informace o těchto komponentách naleznete na následujících stránkách projektu:

Můžete také: