Wdrażanie usług HTTPS na platformie Magnum Kubernetes w NSIS Cloud
Kubernetes umożliwia bardzo szybkie wdrożenie i publiczne udostępnienie aplikacji, na przykład przy użyciu typu usługi LoadBalancer. Przykładowe wdrożenia, które demonstrują takie możliwości, są zwykle obsługiwane za pomocą protokołu HTTP. Wdrożenie usługi gotowej do produkcji, zabezpieczonej protokołem HTTPS, można również wykonać sprawnie, korzystając z dodatkowych narzędzi.
W tym artykule pokazujemy, jak wdrożyć przykładową usługę chronioną protokołem HTTPS w chmurze NSIS.
Co będziemy omawiać
Zainstaluj niestandardowe definicje zasobów programu Cert Manager
Instalacja Cert Manager Helm chart
Tworzenie wdrożenia i usługi
Tworzenie i wdrażanie emitenta
Skojarz domenę z NGINX Ingress
Tworzenie i wdrażanie zasobów Ingress
Wymagania wstępne
Nr 1 Konto
Potrzebne jest konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.
Nr 2 Klaster Kubernetes wdrożony na chmurze, z włączonym NGINX Ingress
Zobacz ten artykuł Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum
Nr 3 Znajomość kubectl
Dalsze instrukcje można znaleźć w Jak uzyskać dostęp do klastra Kubernetes po wdrożeniu przy użyciu Kubectl na NSIS OpenStack Magnum?.
Nr 4 Znajomość funkcji Kubernetes Ingress
Jest to wyjaśnione w artykule Korzystanie z Kubernetes Ingress w NSIS OpenStack Magnum
Nr 5 Znajomość obsługi wykresów Helm
Zobacz ten artykuł:
Wdrażanie Helm Charts na klastrach Magnum Kubernetes w chmurze NSIS Cloud
Nr 6 Musi mieć domenę zakupioną u rejestratora
Musisz także posiadać domenę zakupioną od dowolnego rejestratora (odsprzedawcy domen). Uzyskanie domeny od rejestratorów nie jest przedmiotem tego artykułu.
Nr 7 Użyj polecenia DNS Horizon, aby połączyć się z nazwą domeny
Jest to opcjonalne. Tutaj znajduje się artykuł ze szczegółowymi informacjami:
Krok 1 Zainstaluj niestandardowe definicje zasobów (CRD) programu Cert Manager
Zakładamy, że posiadasz
Klaster Magnum uruchomiony i działający
kubectl wskazujący na plik config klastra.
W ramach kontroli wstępnej można wyświetlić listę węzłów w klastrze:
# export KUBECONFIG=<your-kubeconfig-file-location>
kubectl get nodes
CertManager Helm chart wykorzystuje kilka Custom Resource Definitions (CRD), które będziemy musieli wdrożyć w naszym klastrze. Oprócz wielu domyślnych zasobów dostępnych w Kubernetes (np. Pods, Deployments lub Services), CRD umożliwiają wdrażanie niestandardowych zasobów zdefiniowanych przez zewnętrznych programistów w celu zaspokojenia dalszych niestandardowych przypadków użycia. Dodajmy CRD do naszego klastra za pomocą następującego polecenia:
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.9.2/cert-manager.crds.yaml
Lista zasobów zostanie wyświetlona po uruchomieniu polecenia. Jeśli chcemy później odwołać się do nich, możemy również użyć następującego polecenia kubectl:
kubectl get crd -l app.kubernetes.io/name=cert-manager
...
NAME CREATED AT
certificaterequests.cert-manager.io 2022-12-18T11:15:08Z
certificates.cert-manager.io 2022-12-18T11:15:08Z
challenges.acme.cert-manager.io 2022-12-18T11:15:08Z
clusterissuers.cert-manager.io 2022-12-18T11:15:08Z
issuers.cert-manager.io 2022-12-18T11:15:08Z
orders.acme.cert-manager.io 2022-12-18T11:15:08Z
Ostrzeżenie
Magnum wprowadza kilka PodSecurityPolicy (PSP), które zapewniają dodatkowe środki ostrożności dla klastra, ale powodują konflikt z CertManager Helm chart. PodSecurityPolicy jest przestarzała do wersji Kubernetes 1.25, ale nadal obsługiwana w wersjach Kubernetes 1.21 do 1.23 dostępnych w chmurze NSIS. Poniższe polecenia mogą generować ostrzeżenia o przestarzałości, ale mimo to instalacja powinna być kontynuowana.
Krok 2 Zainstaluj CertManager Helm chart
Zakładamy, że zainstalowałeś Helm zgodnie z artykułem wspomnianym w Warunku wstępnym nr 5. Wynikiem tego artykułu będzie plik my-values.yaml i aby zapewnić prawidłowe wdrożenie wykresu CertManager Helm, będziemy musieli
nadpisać go i
wstawić do niego odpowiednią zawartość:
my-values.yaml
global:
podSecurityPolicy:
enabled: true
useAppArmor: false
Poniższy kod zainstaluje wykres CertManager Helm w przestrzeni nazw cert-manager i jednocześnie użyje my-values.yaml:
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.9.2 --values my-values.yaml
Oto rezultat:
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.9.2 --values my-values.yaml
W0208 10:16:08.364635 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:08.461599 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:08.502602 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:11.489377 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:11.489925 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:11.524300 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:13.949045 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:16:15.038803 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0208 10:17:36.084859 212 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
NAME: cert-manager
LAST DEPLOYED: Wed Feb 8 10:16:07 2023
NAMESPACE: cert-manager
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
cert-manager v1.9.2 has been deployed successfully!
In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).
Widzimy, że cert-manager został pomyślnie wdrożony, ale otrzymujemy również wskazówkę, że ClusterIssuer lub zasób Issuer również musi zostać zainstalowany. Naszym następnym krokiem jest zainstalowanie przykładowej usługi w klastrze, a następnie kontynuowanie tworzenia i wdrażania Issuer.
Krok 3 Tworzenie wdrożenia i usługi
Wdróżmy usługę NGINX jako standardowy przykład aplikacji Kubernetes. Najpierw tworzymy standardowe wdrożenie Kubernetes, a następnie usługę typu NodePort. Wpisz następującą zawartość do pliku my-nginx.yaml :
my-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx-deployment
spec:
selector:
matchLabels:
run: my-nginx
replicas: 1
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: my-nginx-service
labels:
run: my-nginx
spec:
type: NodePort
ports:
- port: 80
protocol: TCP
selector:
run: my-nginx
Wdróż za pomocą następującego polecenia:
kubectl apply -f my-nginx.yaml
Krok 4 Utworzenie i wdrożenie emitenta
Teraz zainstaluj Issuer. Jest to niestandardowy zasób Kubernetes i reprezentuje urząd certyfikacji (CA), który zapewnia, że nasze HTTPS są podpisane, a zatem zaufane przez przeglądarki. CertManager obsługuje różnych wystawców, w naszym przykładzie użyjemy Let’s Encrypt, który używa protokołu ACME.
Utwórz nowy plik o nazwie my-nginx-issuer.yaml i wklej do niego poniższą zawartość. Zmień adres e-mail XXXXXXXXX@YYYYYYYYY.com na swój własny i prawdziwy adres e-mail.
my-nginx-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: my-nginx-issuer
spec:
acme:
email: [email protected]
server: https://acme-v02.api.letsencrypt.org/directory # production
privateKeySecretRef:
name: letsencrypt-secret # different secret name than for ingress
solvers:
# HTTP-01 challenge provider, creates additional ingress, refer to CertManager documentation for detailed explanation
- http01:
ingress:
class: nginx
Następnie wdrożyć w klastrze:
kubectl apply -f my-nginx-issuer.yaml
W rezultacie Issuer zostaje wdrożony, a Secret o nazwie letsencrypt-secret z kluczem prywatnym zostaje również wdrożony.
Krok 5 Powiązanie domeny z NGINX Ingress
Aby zobaczyć witrynę w przeglądarce, certyfikat HTTPS musi być powiązany z określoną domeną. Aby kontynuować, powinieneś mieć prawdziwą domenę już zarejestrowaną u rejestratora domen.
Po wdrożeniu klastra z NGINX ingress, za kulisami został wdrożony LoadBalancer z publicznym adresem IP. Adres ten można uzyskać, wyszukując go w interfejsie internetowym Horizon. Jeśli lista pływających adresów IP jest dłuższa, można je łatwo rozpoznać po nazwie:
Teraz u rejestratora domeny musisz powiązać rekord A domeny z pływającym adresem IP wejścia, na którym będzie wystawiona Twoja aplikacja. Sposób osiągnięcia tego celu będzie się różnić w zależności od konkretnego rejestratora, więc nie będziemy tutaj podawać szczegółowych instrukcji.
Można również użyć polecenia DNS w programie Horizon, aby połączyć posiadaną nazwę domeny z klastrem. Dodatkowe informacje można znaleźć w warunku wstępnym nr 7.
Krok 6 Utworzenie i wdrożenie zasobu Ingress
Ostatnim krokiem jest wdrożenie zasobu Ingress. Spowoduje to wykonanie niezbędnych kroków w celu zainicjowania żądania podpisania certyfikatu z CA i ostatecznie dostarczenia certyfikatu HTTPS dla usługi. Aby kontynuować, umieść poniższą zawartość w pliku my-nginx-ingress.yaml. Zastąp mysampledomain.eu swoją domeną.
my-nginx-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-nginx-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
# below annotation is for using cert manager's "ingress shim", refer to CertManager documentation
cert-manager.io/issuer: my-nginx-issuer # use the name of the issuer here
spec:
ingressClassName: nginx
tls:
- hosts:
- mysampledomain.eu #change to own domain
secretName: my-nginx-secret
rules:
- host: mysampledomain.eu #change to own domain
http:
paths:
- path: /*
pathType: Prefix
backend:
service:
name: my-nginx-service
port:
number: 80
Następnie wdróż za pomocą:
kubectl apply -f my-nginx-ingress.yaml
Jeśli wszystko działa dobrze, wysiłek został zakończony i po kilku minutach powinniśmy zobaczyć znak kłódki przed naszym adresem IP. Usługa jest teraz zabezpieczona protokołem HTTPS, a szczegóły certyfikatu można zweryfikować, klikając ikonę kłódki.
Co robić dalej
Artykuł Korzystanie z Kubernetes Ingress w NSIS OpenStack Magnum pokazuje jak stworzyć usługę lub stronę opartą na HTTP.
Jeśli potrzebujesz dodatkowych informacji na temat wykresów Helm: Wdrażanie Helm Charts na klastrach Magnum Kubernetes w chmurze NSIS Cloud.