Wdrażanie usług HTTPS na platformie Magnum Kubernetes w NSIS Cloud
Kubernetes umożliwia bardzo szybkie wdrażanie 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 użycia produkcyjnego, 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 zostanie omówione?
Instalacja niestandardowych definicji zasobów programu Cert Manager
Instalacja wykresu Helm Cert Manager
Tworzenie wdrożenia i usługi
Tworzenie i wdrażanie wystawcy certyfikatu
Kojarzenie domeny z kontroleram Ingress NGINX
Tworzenie i wdrażanie zasobów Ingress
Wymagania wstępne
Nr 1 Konto
Jest wymagane konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.
Nr 2 Klaster Kubernetes wdrożony w chmurze z włączonym kontrolerem NGINX Ingress
Zobacz artykuł Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum
Nr 3 Znajomość kubectl
Więcej instrukcji można znaleźć w artykule Jak uzyskać dostęp do klastra Kubernetes po wdrożeniu przy użyciu Kubectl na NSIS OpenStack Magnum?.
Nr 4 Znajomość funkcji Kubernetes Ingress
Są one wyjaśnione w artykule Korzystanie z Kubernetes Ingress w OpenStack Magnum w NSIS Cloud
Nr 5 Znajomość obsługi pakietów chart Helm
Zobacz artykuł:
Wdrażanie Helm Charts na klastrach Magnum Kubernetes w chmurze NSIS
Nr 6 Wymagana domena wykupiona u rejestratora
Musisz także mieć domenę zakupioną od dowolnego rejestratora (sprzedawcy domen). Uzyskanie domeny od rejestratorów nie jest przedmiotem tego artykułu.
Nr 7 Użycie polecenia DNS Horizon, aby połączyć się z nazwą domeny
Jest to opcjonalne. Szczegółowe informacje zawiera artykuł:
Krok 1 Zainstaluj niestandardowe definicje zasobów (CRD) programu Cert Manager
Zakładamy, że masz:
uruchomiony i działający klaster Magnum
kubectl wskazujący na plik config klastra.
W ramach wstępnej kontroli można wyświetlić listę węzłów w klastrze:
# export KUBECONFIG=<your-kubeconfig-file-location>
kubectl get nodes
Wykres Helm dla CertManager 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 (na przykład pody, deployments lub services), CRD umożliwiają wdrażanie niestandardowych zasobów zdefiniowanych przez zewnętrznych programistów w celu zaspokojenia dalszych niestandardowych przypadków zastosowań. 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
Po uruchomieniu polecenia zostanie wyświetlona lista zasobów. Jeśli chcesz później odwołać się do nich, możesz 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 PodSecurityPolicies (PSP), które zapewniają dodatkowe środki ostrożności dla klastra, ale powodują konflikt z wykresem Helm CertManager.PodSecurityPolicy jest wycofana od wersji Kubernetes 1.25, ale nadal jest obsługiwana w wersjach Kubernetes 1.21 do 1.23 dostępnych w chmurze NSIS. Poniższe polecenia mogą generować ostrzeżenia o wycofaniu, ale mimo to instalacja powinna być kontynuowana.
Krok 2 Zainstaluj wykres Helm CertManager
Zakładamy, że Helm został zainstalowany zgodnie z artykułem wspomnianym w sekcji Wymaganie wstępne nr5. Wynikiem czynności opisanych w tym artykule będzie plik my-values.yaml. Aby zapewnić prawidłowe wdrożenie wykresu Helm dla CertManager Helm, należy:
nadpisać go i
wstawić do niego odpowiednią zawartość:
my-values.yaml
global:
podSecurityPolicy:
enabled: true
useAppArmor: false
Poniższy kod zainstaluje wykres Helm CertManager w przestrzeni nazw cert-manager i jednocześnie użyje ustawień z pliku 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
Wynik jest następujący:
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 zasób ClusterIssuer lub 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 wystawcy certyfikatu.
Krok 3 Tworzenie wdrożenia i usługi
Wdróżmy usługę NGINX jako standardowy przykład aplikacji Kubernetes. Najpierw stworzymy 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
Wykonaj wdrożenie za pomocą następującego polecenia:
kubectl apply -f my-nginx.yaml
Krok 4 Utworzenie i wdrożenie wystawcy certyfikatu
Teraz zainstaluj Issuer. Jest to niestandardowy zasób Kubernetes i reprezentuje urząd certyfikacji (CA), który zapewnia, że nasze połączenia HTTPS są podpisane, a zatem traktowane jako 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 własny, prawdziwy adres e-mail.
my-nginx-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: my-nginx-issuer
spec:
acme:
email: XXXXXXXXX@YYYYYYYYY.com
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 umieść go w klastrze:
kubectl apply -f my-nginx-issuer.yaml
W rezultacie Issuer zostaje wdrożony, podobnie jak tajny kod o nazwie letsencrypt-secret z kluczem prywatnym.
Krok 5 Powiązanie domeny z NGINX Ingress
Aby można było wyświetlić witrynę w przeglądarce, certyfikat HTTPS musi być powiązany z określoną domeną. Aby kontynuować, musisz mieć prawdziwą domenę zarejestrowaną u rejestratora domen.
Po wdrożeniu klastra z NGINX ingress, w tle został wdrożony LoadBalancer z publicznym adresem IP. Adres ten można uzyskać, wyszukując go w interfejsie internetowym Horizon. Jeśli lista adresów floating IP jest dłuższa, można go łatwo rozpoznać po nazwie:
Teraz u rejestratora domeny musisz powiązać rekord A domeny z adresem floating IP dla ruchu przychodzącego, na którym będzie udostępniona Twoja aplikacja. Sposób wykonania tej czynności 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 Horizon, aby połączyć posiadaną nazwę domeny z klastrem. Dodatkowe informacje można znaleźć w sekcji Wymaganie wstępne nr7.
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 nazwą swojej domeny.
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 wykonaj wdrożenie za pomocą polecenia:
kubectl apply -f my-nginx-ingress.yaml
Jeśli wszystko działa prawidłowo, proces 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ółowe informacje o certyfikacie można sprawdzić, klikając ikonę kłódki.
Co można zrobić dalej?
Artykuł Korzystanie z Kubernetes Ingress w OpenStack Magnum w NSIS Cloud pokazuje, jak stworzyć usługę lub stronę opartą na protokole HTTP.
Jeśli potrzebujesz dodatkowych informacji na temat pakietów chart Helm, zobacz artykuł: Wdrażanie Helm Charts na klastrach Magnum Kubernetes w chmurze NSIS.