티스토리 뷰
9. 서비스 로드 밸런서 인그레스
인그레스는 서비스 오브젝트를 로드밸런싱하는 리소스입니다.
우리는 이미 인그레스를 통해 서비스를 로드밸런싱 해 봤습니다.
인그레스에 대해 무엇을 더 알아야 할까요 ?
어떻게 인그레스가 외부의 트래픽을 받는지 원리를 알고 싶지 않나요 ?
또 HTTP 뿐 아니라 HTTPS를 사용하여 TLS 통신을 하는 방법이 궁금하시지 않나요 ?
그래서 이번에는 인그레스의 원리를 먼저 알아보고 인그레스를 이용한 HTTPS 통신 방법을 알아 보겠습니다.
세번째로는 인그레스 없이 별도의 웹서버를 세우고 NodePort서비스를 프락싱하는 방법을 배워 보겠습니다.
인그레스의 목적은 외부 트래픽을 클러스터 내부로 연결해 주는 것이기 때문에 이미지나 자바스크립트와 같은 정적 컨텐츠를 캐싱하는 방법을 제공하지 않습니다.
어차피 제일 앞단에 웹서버를 만들거라면 굳이 인그레스를 거치지 않고 바로 서비스를 프락싱하는게 더 나을 수 있습니다.
9.1 인그레스의 원리
쿠버네티스 설치 과정의 마지막 쯤에 인그레스 컨트롤러라는 것을 설치 하셨을 겁니다.
이 인그레스 컨트롤러가 없으면 인그레스 오브젝트를 만들어도 외부의 트래픽을 받을 수 없습니다.
인그레스 컨트롤러는 ‘ingress-nginx’ 네임 스페이스에 설치되어 있습니다.
그 네임 스페이스의 서비스 오브젝트를 보면 아래와 같이 ‘ingress-nginx-controller’라는 오브젝트가 보입니다.
External IP가 클러스터 VM의 퍼블릭 IP로 되어 있고 서비스 내부 포트는 80과 443입니다.
[root@osboxes certs]# k get svc -n ingress-nginx NAME TYPE … EXTERNAL-IP PORT(S) ingress-nginx-controller ClusterIP 169.56.70.197,169.56.70.201 80/TCP,443/TCP … |
실행되는 파드를 보면 1개가 실행되고 있습니다.
[root@osboxes certs]# k get po -n ingress-nginx NAME READY STATUS RESTARTS AGE ingress-nginx-admission-create-sj8sq 0/1 Completed 0 14d ingress-nginx-admission-patch-cmndw 0/1 Completed 0 14d ingress-nginx-controller-6c48f768ff-4xkw5 1/1 Running 0 20h |
바로 이 ‘ingress-nginx-controller’ 서비스 오브젝트가 외부로의 트래픽을 제일 처음 받아서 ‘ingress-nginx-controller-xxx’파드를 연결해 줍니다.
‘ingress-nginx-controller-xxx’파드는 특수한 nginx 서버 입니다. 파드 안으로 들어가서 nginx의 컨피그레이션 파일인 ‘nginx.conf’의 내용을 봅시다.
밑으로 한참을 내려 보면 여러분이 만든 인그레스 호스트에 대한 설정들이 있습니다.
[root@osboxes certs]# k exec -it ingress-nginx-controller-6c48f768ff-4xkw5 -n ingress-nginx -- sh /etc/nginx $ vi nginx.conf … ## start server ott.169.56.70.201.nip.io server { server_name ott.169.56.70.201.nip.io ; listen 80 ; listen [::]:80 ; listen 443 TLS http2 ; listen [::]:443 TLS http2 ; … location ~* "^/recommend/(.*)" { … } … |
/etc/nginx $ exit |
‘ingress-nginx-controller-xxx’파드는 실행을 시작할 때 인그레스 오브젝트들을 찾아서 nignx.conf파일에 등록을 합니다. 실제로 외부의 트래픽을 클러스터 내부로 연결하는 것은 이 파드에 실행된 nginx 서버가 되는 것입니다.
그래서 외부의 트래픽이 내부로 전달되는 과정을 요약하면 아래와 같습니다.
결론적으로 외부의 트래픽을 내부로 전달하는 것은 인그레스가 아니라 인그레스 컨트롤러 서비스인것입니다.
인그레스 컨트롤러 제품들은 nginx 외에도 많이 있습니다. 쿠버네티스 커뮤니티에서 공식적으로 운영하는 제품은 AWS, GCE, nginx 인크레스 컨트롤러입니다.
그 외 3rd 파티 제품들은 아래 글을 참고 하십시오.
https://kubernetes.io/ko/docs/concepts/services-networking/ingress-controllers/
9.2 인그레스에 HTTPS 적용
인그레스에 HTTPS를 적용하는 작업 순서를 알아보고 테스트 인증서를 만들어 적용해 보겠습니다.
그리고 Let’s Encrypt라는 비영리 기관에서 제공하는 무료 정식 인증서를 발급 받아 적용까지 해 보겠습니다.
1) 인그레스에 HTTPS 적용 순서
인그레스에 HTTPS를 적용하는 방법은 매우 간단합니다.
아래 야믈 파일 내용에서 ‘spec.tls’항목을 보십시오. 이 항목을 추가하고 TLS인증서를 갖고 있는 시크릿만 지정해 주면 됩니다.
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx kubernetes.io/TLS-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$1 name: ott namespace: ott spec: tls: - secretName: ott rules: - host: ott.169.56.70.201.nip.io http: paths: - path: /member/(.*) pathType: Prefix backend: service: name: member port: number: 3001 - path: /recommend/(.*) pathType: Prefix backend: service: name: recommend port: number: 3002 |
그럼 TLS인증서를 담고 있는 시크릿 오브젝트를 어떻게 만들까요 ?
그 전에 TLS인증서는 어떻게 만들까요 ?
TLS 인증서는 공인된 기관에서 구매하면 됩니다. ‘TLS 인증서 구매'로 구글링 하시면 여러 업체에서 서비스를 제공하고 있으니 적절한 업체를 선정해서 구매 하십시오.
각 FQDN별로 구매하거나 와일드카드 도메인으로 구매할 수 있습니다.
예를 들어 ‘ott.kubepia.com’으로 구매하거나 ‘*.kubepia.com’으로 구매할 수 있습니다.
물론 와일드카드 도메인이 더 비싸고요.
구매를 하면 인증서 파일들을 보내 오는데 웹서버와 OS에 따라 인증서 파일의 확장자가 다릅니다.
인증서 파일의 종류를 아래에 정리했으니 참고 하십시오.
여기서 중요한 파일이 인증서와 개인키입니다.
보통 인증서는 확장자로 ‘pem’이나 ‘crt’를 많이 쓰고 개인키는 확장자로 ‘pem’이나 ‘key’를 사용합니다.
인증서 관련 파일 종류
- 인증서: pem-표준, crt-유닉스/리눅스에서 많이 사용, cer-윈도우에서 많이 사용
- 인증서 발급 요청서: csr
- 개인키: key, pem
- 개인키+인증서: pfx/p12(윈도우), jks(Tomcat)
인증서 파일을 받은 후 이 파일들을 이용하여 시크릿을 아래와 같이 만드십시오.
kubectl create secret tls {시크릿명} --key {개인키 파일 경로} --cert {인증서 파일 경로} [-n {네임스페이스}]
예) kubectl create secret tls ott --key ./privkey.pem --cert ./fullchain.pem -n ott
그리고 인그레스 정의 야믈 파일의 ‘spec.tls’에 위 시크릿 오브젝트의 이름을 지정하면 됩니다.
2) 테스트 인증서 발급 및 적용
인증서는 개인키 발급 ⇒ 인증서 발급 요청서 생성 ⇒ 인증서 발급의 순서로 만듭니다.
리눅스에서 기본으로 제공하는 ‘openssl’이라는 프로그램을 이용해서 만듭니다.
배천 노드에 ‘~/k8s/certs’디렉토리를 만든 후 이동 하십시오.
[root@osboxes ~]# mkdir -p ~/k8s/certs && cd ~/k8s/certs |
‘ott.key’라는 파일명으로 개인키를 만듭니다. 아래와 같이 뭔가 난수같은 내용을 담은 개인키 파일이 생성 됩니다.
[root@osboxes certs]# openssl genrsa -out ./ott.key 4096 Generating RSA private key, 4096 bit long modulus (2 primes) [root@osboxes certs]# cat ott.key -----BEGIN RSA PRIVATE KEY----- MIIJKQIBAAKCAgEAyKtqVnAEAdspGQ9o ... ... yGfZN123sBFP4i7cijvjnAoeoGk0e5h4NPDNXBJCgpPs0Is -----END RSA PRIVATE KEY----- |
인증서 발급 요청서를 ‘ott.csr’이라는 파일명으로 만드십시오.
요청서의 각 항목을 입력하여 만들면 됩니다. 제일 중요한 항목은 ‘Common Name’입니다.
다른 항목들은 입력 안하셔도 됩니다. Common Name에 인그레스의 ‘host’에 정의한 FQDN을 똑같이 입력 합니다.
[root@osboxes certs]# openssl req -new -key ott.key -out ott.csr … ----- Country Name (2 letter code) [XX]:KR State or Province Name (full name) []:Seoul Locality Name (eg, city) [Default City]: Organization Name (eg, company) [Default Company Ltd]:HappyCloudTech Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:ott.169.56.70.201.nip.io Email Address []:hiondal@gmail.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: |
<주의>
위 예의 Common Name을 그대로 입력하면 안됩니다. 반드시 인그레스 오브젝트의 FQDN을 확인하고 그 값을 입력 하십시오.
‘kubectl get ing’로 확인하면 됩니다.
</>
인증서 파일을 ‘ott.crt’라는 파일명으로 만듭니다. -days뒤에 인증서 유효기간을 지정할 수 있습니다.
[root@osboxes certs]# openssl x509 -req -days 3650 -in ott.csr -signkey ott.key -out ott.crt Signature ok subject=C = KR, ST = Seoul, L = Default City, O = HappyCloudTech, CN = ott.169.56.70.201.nip.io, emailAddress = hiondal@gmail.com Getting Private key [root@osboxes certs]# cat ott.crt -----BEGIN CERTIFICATE----- MIIFrTCCA5UCFAPQysryh2UxOuF1U6… … WtLME1qryn5r+iQzdNGaPSU= -----END CERTIFICATE----- |
이제 ‘ott’라는 이름으로 시크릿 오브젝트를 만듭니다.
[root@osboxes certs]# k create secret tls ott --key ott.key --cert ott.crt -n ott secret/ott created |
‘~/k8s/yaml’로 이동하여 인그레스 정의 야믈파일을 다운로드 하십시오.
[root@osboxes yaml]# wget -O ing-ott-tls.yaml https://hiondal.github.io/k8s-yaml/3.4/ing-ott.yaml --2022-01-15 01:58:45-- https://hiondal.github.io/k8s-yaml/3.4/ing-ott.yaml [root@osboxes yaml]# vim ing-ott-tls.yaml |
그리고 ‘spec.tls’항목을 아래와 같이 추가 하십시오.
apiVersion: networking.k8s.io/v1 … spec: tls: - secretName: ott rules: … |
기존 인그레스 오브젝트를 지우고 다시 만드십시오.
[root@osboxes yaml]# k delete ing ott ingress.networking.k8s.io "ott" deleted [root@osboxes yaml]# k apply -f ing-ott-tls.yaml ingress.networking.k8s.io/ott created |
자 이제 웹브라우저에서 HTTPS로 ‘member’ API와 ‘recommend’ API를 호출해 보십시오.
에를 들면 ‘https://ott.169.56.70.201.nip.io/member/members/user1’과 같이요.
보안 경고 페이지가 먼저 나올겁니다. [고급] 버튼을 누르고 맨 아래 링크를 누르십시오.
테스트 TLS 인증서이기 때문에 보안 경고 페이지가 나오는 겁니다.
아래와 같이 HTTPS로 API가 정상적으로 호출 되면 성공입니다.
보안 경고 페이지는 최초에 한번만 나오지만 저 페이지를 없애고 싶으시겠죠 ?
실제 서비스를 한다고 하면 저런 무시 무시한 경고 페이지가 나오면 절대 안되니까 말이죠.
이제 무료로 정식 TLS 인증서를 발급 받아 보안 경고 페이지를 없애 보겠습니다.
3) 정식 인증서 발급 및 적용
Let’s Encrypt(https://letsencrypt.org/ko/)라는 비영리 단체에서 무료로 제공하는 정식 TLS 인증서를 발급 받아 인그레스에 적용하겠습니다.
이 단체는 보다 안전한 웹 사용 환경을 위해 TLS인증서를 무료로 제공하고 있습니다.
인증서를 발급 받기 위해서는 인증서를 만드는 VM에 80포트로 수신하는 웹서버가 하나 있어야 합니다.
따라서 인그레스 호스트로 지정한 VM에 nginx 웹서버를 설치해야 인증서를 발급 받을 수 있습니다.
인그레스 호스트에는 아마 워커노드의 IP를 이용하여 FQDN이 등록되어 있을겁니다.
저 같은 경우는 ott.169.56.70.201.nip.io로 되어 있고 ‘169.56.70.201’은 워커노드의 IP입니다.
어쨌든 인그레스 호스트로 지정된 VM으로 로그인하여 nginx 서버를 먼저 설치 합니다.
그 전에 중요하게 할 일이 있습니다.
인그레스 컨트롤러 서비스 오브젝트에서 External IP로 등록한 VM 중 인증서를 발급할 VM은 잠깐 빼야 합니다.
왜냐하면 External IP로 노출한 VM에는 자동으로 인그레스 컨트롤러가 80포트를 점유하기 때문입니다.
아래와 같이 인그레스 컨트롤러 서비스 오브젝트를 편집하여 인증서를 발급할 VM의 IP는 제거 하십시오.
[root@osboxes ~]# k edit svc ingress-nginx-controller -n ingress-nginx |
... spec: clusterIP: 10.98.216.94 clusterIPs: - 10.98.216.94 externalIPs: - 169.56.70.197 #- 169.56.70.201 ... |
인증서를 발급할 VM을 로그인 합니다.
[root@osboxes ~]# ssh w1 |
nginx 설치를 위한 리포지토리를 추가하고 nginx 서버를 설치 합니다.
[root@worker1 ~]# cat <<EOF > /etc/yum.repos.d/nginx.repo [nginx] name=nginx repo baseurl=http://nginx.org/packages/centos/8/x86_64/ gpgcheck=0 enabled=1 EOF [root@worker1 ~]# dnf install -y nginx |
nginx서버를 실행 합니다.
[root@worker1 ~]# systemctl enable nginx --now [root@worker1 ~]# systemctl status nginx ● nginx.service - The nginx HTTP and reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled) Active: active (running) since 일 2022-01-16 08:57:17 CST; 13h ago |
웹브라우저에서 연결 되는지 확인 합니다. VM의 퍼블릭 IP를 입력합니다.
Let’s Encrypt의 TLS 인증서 발급을 해주는 ‘certbot’이라는 프로그램을 설치 합니다.
아래 링크에 웹서버 종류와 OS이 따라 설치하는 가이드가 잘 나와 있습니다.
https://certbot.eff.org/instructions
우리는 CentOS 8 + nginx에 설치하면 됩니다. 그 외 웹서버나 OS에 설치할 때는 위 링크 글을 그대로 따라 하시면 됩니다.
certbot을 설치해 주는 snapd부터 설치 합니다.
[root@worker1 ~]# dnf install -y epel-release [root@worker1 ~]# dnf install -y snapd [root@worker1 ~]# systemctl enable --now snapd.socket [root@worker1 ~]# ln -s /var/lib/snapd/snap /snap |
snapd 설치 후 2~3분 기다렸다가 ‘core’라는 걸 설치하고 최신 버전으로 업데이트 합니다.
[root@worker1 ~]# snap install core [root@worker1 ~]# snap refresh core |
certbot을 설치 합니다. 기존에 다른 버전의 certbot이 설치되어 있다면 지우시고 설치 하십시오.
[root@worker1 ~]# dnf remove certbot [root@worker1 ~]# snap install --classic certbot [root@worker1 ~]# ln -s /snap/bin/certbot /usr/bin/certbot |
이제 인증서 발급 준비가 끝났습니다.
아래 명령으로 인증서를 발급 합니다.
email을 입력하고 정책과 이메일 등록에 동의합니다.
제일 중요한 것은 도메인 이름을 입력하는 부분입니다. 인그레스 호스트에 지정한 이름과 동일하게 입력 합니다.
지금은 DNS가 없어서 와일드카드 DNS형식을 이용하지만 실제로는 DNS에 FQDN을 등록하시고 그 이름으로 발급 받으면 됩니다.
[root@worker1 ~]# certbot certonly --nginx Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): hiodal@gmail.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server. Do you agree? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: Y - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing, once your first certificate is successfully issued, to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: Y Account registered. Please enter the domain name(s) you would like on your certificate (comma and/or space separated) (Enter 'c' to cancel): ott.169.56.70.201.nip.io Requesting a certificate for app.ott.kubepia.com Successfully received certificate. Certificate is saved at: /etc/letsencrypt/live/ott.169.56.70.201.nip.io/fullchain.pem Key is saved at: /etc/letsencrypt/live/ott.169.56.70.201.nip.io/privkey.pem This certificate expires on 2022-04-16. |
맨 아래쯤에 인증서가 어느 경로에 발급되었는지 보여 줍니다.
fullchain.pem이 인증서 파일이고 privkey,pem파일이 개인키 파일입니다.
이제 이 인증서 파일들을 이용해서 시크릿을 만듭니다.
기존 시크릿을 지웁니다. 워커노드는 ‘kubectl’의 별명인 ‘k’를 안 만들었으므로 ‘kubectl’으로 하셔야 합니다.
인증서 파일이 있는 디렉토리로 이동하시고 만드시는게 편합니다.
[root@osboxes worker1]# kubectl delete secret ott -n ott [root@osboxes worker1]# cd /etc/letsencrypt/live/ott.169.56.70.201.nip.io [root@worker1 ott.169.56.70.201.nip.io]# kubectl create secret tls ott --key ./privkey.pem --cert fullchain.pem -n ott |
다시 인그레스 컨트롤러 서비스의 External IP에 현재 VM의 IP를 추가해야 합니다.
그전에 80포트를 사용하고 있는 nginx서버를 중단합니다.
[root@worker1 ott.169.56.70.201.nip.io]# systemctl stop nginx |
[root@worker1 ott.169.56.70.201.nip.io]# kubectl edit svc ingress-nginx-controller -n ingress-nginx |
... spec: clusterIP: 10.98.216.94 clusterIPs: - 10.98.216.94 externalIPs: - 169.56.70.197 - 169.56.70.201 #- 169.56.70.201 ... |
이제 배천노드로 돌아와서 인그레스 컨트롤러를 지우고 다시 생성 하십시오.
[root@osboxes yaml]# k delete -f ing-ott-tls.yaml ingress.networking.k8s.io "ott" deleted [root@osboxes yaml]# k apply -f ing-ott-tls.yaml ingress.networking.k8s.io/ott created |
드디어 확인할 시간입니다
웹브라우저를 열고 ‘member’ API를 HTTPS로 접근 합니다.
이제는 기분 나쁜 보안 경고창 없이 페이지가 잘 열릴겁니다.
크롬의 경우 아래와 같이 인증서 정보를 볼 수 있습니다.
사용 만료일을 보면 발급일로 부터 3개월임을 알 수 있습니다.
무료 버전이라 3개월로 기간 제한을 하지만 3개월씩 연장할 수 있습니다.
리눅스의 크론탭 기능을 이용하여 아래 명령을 안전하게 2개월마다 수행하십시오.
그럼 명령이 수행되는 웹서버에 발급된 인증서가 자동 갱신 됩니다.
간단하게 쉘 스크립트를 짜서 인증서 갱신과 시크릿 재 생성까지 하시면 계속 인증서를 사용할 수 있습니다.
certbot renew
9.3 인그레스 없이 웹 서버로 프락싱 하기
이번에는 웹서버에서 NodePort서비스를 프락싱하여 인그레스를 대신하는 방법을 실습해 보겠습니다.
실무에서는 웹서버를 맨 앞에 배치하여 게이트웨이를 연결하고 게이트웨이가 밴엔드의 파드를 연결하는 아키텍처도 많이 사용 합니다.
우리는 게이트웨이가 없으니 서비스 오브젝트를 바로 프락싱하겠습니다.
이를 위해서는 웹서버용 VM이 필요하니 클라우드에서 한 대 더 구매해 주십시오.
퍼블릭 IP가 있는 VM이면 되므로 어떤 클라우드 벤더라도 상관 없습니다.
IBM 클라우드에서 구매한다면 아래와 같이 최소 비용으로 VM을 만드시면 됩니다.
OS는 CentOS 7을 선택 하십시오.
생성한 VM을 로그인 한 후 OS를 먼저 업그레이드 합니다.
저는 hostnamectl set-hostname web 명령으로 호스트명을 ‘web’으로 변경했습니다. 이 작업은 굳이 안해도 됩니다.
[root@web ~]# dnf upgrade -y |
nginx 서버를 설치 하십시오.
[root@worker1 ~]# cat <<EOF > /etc/yum.repos.d/nginx.repo [nginx] name=nginx repo baseurl=http://nginx.org/packages/centos/7/x86_64/ gpgcheck=0 enabled=1 EOF [root@worker1 ~]# dnf install -y nginx |
실제 환경에서는 파이어월firewall이 있어야 하므로 아래와 같이 firewall을 실행하고 80과 443포트를 허용하십시오..
[root@web ~]# systemctl enable firewalld --now [root@web ~]# firewall-cmd --permanent --zone=public --add-port=80/tcp success [root@web ~]# firewall-cmd --permanent --zone=public --add-port=443/tcp success [root@web ~]# firewall-cmd --reload success [root@web ~]# firewall-cmd --list-ports 80/tcp 443/tcp |
<팁>
테스트 목적일때는 파이어월을 중단시켜도 됩니다.
systemctl stop firewalld
</>
certbot을 설치하고 인증서를 발급 하십시오.
인증서 발급 도메인은 DNS가 없으니 와일드카드 DNS형식을 이용하십시오.
예를 들어 ‘bestott.169.56.70.205.nip.io’와 같이 하시면 됩니다. 물론 가운데 IP는 여러분 VM의 IP로 하셔야 합니다.
예를 들어 저같은 경우는 아래와 같이 인증서와 개인키 파일을 발행 하였습니다.
Certificate Path: /etc/letsencrypt/live/bestott.169.56.70.205.nip.io/fullchain.pem
Private Key Path: /etc/letsencrypt/live/bestott.169.56.70.205.nip.io/privkey.pem
‘/etc/nginx/conf.d’디렉토리로 이동하여 TLS설정 파일을 만듭니다.
[root@web ~]# cd /etc/nginx/conf.d [root@web ~]# vi tls.conf |
그리고 아래 예제와 같이 ssl_certificate에 인증서 파일의 경로를 넣고 ssl_certificate_key에 개인키 파일의 경로를 넣고 저장 하십시오.
server { listen 443 ssl; access_log /var/log/nginx/access.log; ssl_certificate "/etc/letsencrypt/live/bestott.169.56.70.205.nip.io/fullchain.pem"; ssl_certificate_key "/etc/letsencrypt/live/bestott.169.56.70.205.nip.io/privkey.pem"; ssl_session_cache shared:SSL:1m; ssl_session_timeout 10m; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; location / { root /usr/share/nginx/html; index index.html index.htm; } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } } |
nginx 서버를 재시작 하여 변경 사항을 반영 합니다.
[root@web ~]# systemctl restart nginx |
웹브라우저에서 HTTPS로 웹서버를 열어 봅니다. 잘 연결이 되면 다음으로 진행 합니다.
이제 NodePort 서비스의 프락시 설정을 nginx.conf파일에 합니다.
먼저 ‘member’서비스를 NodePort로 바꾸고 ‘30001’번으로 외부 포트를 지정 하십시오.
[root@osboxes yaml]# k edit svc member |
... spec: ... ports: - name: port1 nodePort: 30001 port: 3001 protocol: TCP targetPort: 3001 ... type: NodePort |
‘recommend’서비스도 NodePort로 바꾸고 ‘30002’번으로 외부 포트를 지정 하십시오.
아래와 같이 PORT(S)컬럼이 나와야 합니다.
[root@osboxes yaml]# k get svc member recommend NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE member NodePort 10.105.194.180 <none> 3001:30001/TCP 37h recommend NodePort 10.99.177.74 <none> 3002:30002/TCP 41h |
웹서버를 로그인하고 ‘/etc/nginx/conf.d/tls.conf’파일을 여십시오.
아래와 같이 ‘/member’와 ‘/recommend’설정을 추가 하십시오.
‘proxy_pass’할 대상 노드 IP는 여러분의 클러스터 VM으로 바꾸셔야 합니다.
server { … location / { root /usr/share/nginx/html; index index.html index.htm; } location /member { rewrite ^/member(.*)$ $1 break; error_log /var/log/nginx/rewrite_debug.log debug; proxy_pass http://169.56.70.201:30001; } location /recommend { rewrite ^/recommend(.*)$ $1 break; error_log /var/log/nginx/rewrite_debug.log debug; proxy_pass http://169.56.70.201:30002; } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } } |
❶ 요청되는 경로입니다.
❷ Rewrite Rule을 정의 합니다. 요청되는 경로에서 ‘/member’를 제거하여 프락시 합니다.
❸ Rewrite 디버그 로그 파일 경로를 지정 합니다.
❹ 프락시할 NodePort 서비스의 FQDN과 외부 포트를 정의 합니다. IP는 여러분 클러스터의 VM중 하나로 바꿔야 합니다.
‘/etc/nginx/conf.d/default.conf’파일에도 ‘/member’와 ‘/recommend’ 프락시 설정을 추가 합니다.
설정 파일을 저장하고 닫은 후 nginx를 재시작 합니다.
[root@web nginx]# systemctl restart nginx |
이제 웹브라우저에서 웹서버의 주소로 ‘member’와 ‘recommend’를 호출해 봅니다.
HTTP와 HTTPS 모두 해 보십시오.
아래와 같이 잘 연결이 되면 성공입니다.
이제 웹서버에 정적 컨텐츠의 캐시 설정이나 타임아웃 설정 등 여러가지를 하여 보다 빠르고 안정적인 서비스를 제공할 수 있습니다.
쿠버네티스 쉽게 이해하기 시리즈 목차
[쿠버네티스 쉽게 이해하기 1] 쿠버네티스 설치하기
[쿠버네티스 쉽게 이해하기 2] 쿠버네티스 아키텍처
[쿠버네티스 쉽게 이해하기 3] 한장으로 이해하는 쿠버네티스 리소스
[쿠버네티스 쉽게 이해하기 4] 쿠버네티스 개발에서 배포까지 실습
[쿠버네티스 쉽게 이해하기 5] 쿠버네티스 오브젝트 정의 파일 쉽게 만들기
[쿠버네티스 쉽게 이해하기 6] 꼭 알아야 할 쿠버네티스 주요 명령어
[쿠버네티스 쉽게 이해하기 7] 파드 실행 및 통제를 위한 워크로드 컨트롤러
[쿠버네티스 쉽게 이해하기 8] 파드 로드 밸런서 서비스
[쿠버네티스 쉽게 이해하기 9] 서비스 로드 밸런서 인그레스
[쿠버네티스 쉽게 이해하기 10] 환경변수 컨피그맵과 시크릿
[쿠버네티스 쉽게 이해하기 11] 데이터 저장소 사용을 위한 PV/PVC
[쿠버네티스 쉽게 이해하기 12] 헬스 체크를 위한 스타트업 프로브, 라이브니스 프로브, 레디니스 프로브
[쿠버네티스 쉽게 이해하기 13] 통합 로깅을 위한 EFK 스택
[쿠버네티스 쉽게 이해하기 14] 인증Authentication과 알백RBAC 방식의 인가Authorization
[쿠버네티스 쉽게 이해하기 15] 더 알면 좋을 주제들: 무중단 배포, 모니터링, HPA
'Cloud > Kubernetes' 카테고리의 다른 글
[쿠버네티스 쉽게 이해하기 11] 데이터 저장소 사용을 위한 PV/PVC (0) | 2022.05.22 |
---|---|
[쿠버네티스 쉽게 이해하기 10] 환경변수 컨피그맵과 시크릿 (0) | 2022.05.22 |
[쿠버네티스 쉽게 이해하기 8] 파드 로드 밸런서 서비스 (0) | 2022.05.22 |
[쿠버네티스 쉽게 이해하기 7] 파드 실행 및 통제를 위한 워크로드 컨트롤러 (0) | 2022.05.22 |
[쿠버네티스 쉽게 이해하기 6] 꼭 알아야 할 쿠버네티스 주요 명령어 (0) | 2022.05.22 |
- Total
- Today
- Yesterday
- spotify
- 분초사회
- 디토소비
- 도파밍
- micro service
- 마이크로서비스 패턴
- API Composition
- 육각형인간
- AXON
- 버라이어티가격
- CQRS
- 스포티파이
- 스핀프로젝트
- agile
- 요즘남편 없던아빠
- 돌봄경제
- Event Sourcing
- 애자일
- 리퀴드폴리탄
- SAGA
- 호모프롬프트
- 마이크로서비스
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |