블로그 | NGINX

마라: 이제 가까운 워크스테이션에서 실행 중

NGINX-F5-수평-검정-유형-RGB의 일부
제이슨 슈미트 썸네일
제이슨 슈미트
2022년 4월 22일 게시

NGINX Modern Apps Reference Architecture (MARA) 프로젝트를 시작했을 때 우리는 IaaS 공급업체로 AWS를 선택했습니다. 이미 해당 플랫폼에 익숙했고, 부서 예산으로 비용을 충당할 수 있었기 때문입니다. 물론 모든 사람이 동일한 경험이나 예산을 가지고 있는 것은 아니며, 여러분 중 많은 분들이 K3s , Canonical MicroK8s , minikube 와 같은 Kubernetes 배포판을 사용하여 실험실 기반 환경이나 워크스테이션에서 MARA를 로컬로 실행할 수 있는 옵션을 제공해 달라고 요청하셨습니다.

여러분의 의견을 듣고 오늘 MicroK8s에서 MARA를 테스트했으며 직접 배포할 수 있도록 지침을 제공하게 되어 기쁩니다!

워크스테이션에서 실행되는 NGINX Modern Apps Reference Architecture의 토폴로지를 보여주는 다이어그램

우리가 테스트에 MicroK8s를 선택한 이유는 무엇입니까? 이 솔루션은 쉽게 배포할 수 있는 모델로 메모리 사용량이 적고 MARA에 필요한 DNS, 스토리지, 송신 기능을 제공합니다. MicroK8s를 사용하면 테스트 시나리오를 쉽고 반복적으로 반복하여 합리적인 수준의 성능을 제공하는 배포에 필요한 최소 요구 사항을 확인할 수 있습니다.

우리는 이 작업을 통해 다른 Kubernetes 배포판에 대한 테스트가 용이해질 것으로 기대합니다. 다양한 배포판의 현재 상태에 대한 정보는 GitHub 저장소를 참조하세요. 목록에 추가하고 싶은 선호하는 배포판이 있으면 포크하고 테스트하고 풀 리퀘스트를 만들어 보세요!

리소스 제약 처리

MARA를 로컬에서 실행하는 데 가장 큰 제약은 메모리와 CPU입니다. 예비 테스트 중에 우리는 메모리 고갈 문제의 대부분이 Elasticsearch와 관련이 있다는 것을 발견했습니다. Kibana는 메모리 양이 매우 적은( 16GB 미만) 구성에서는 거의 사용할 수 없습니다. 이 문제를 해결하기 위해, Elasticsearch 전체 배포에 일반적으로 포함되는 중복 보호 기능을 제거하는 MARA 구성 파일에서 설정을 제공했습니다. 이로 인해 실패 모드의 수가 늘어나지만, 리소스가 제한된 환경에서는 불가피한 타협입니다.

CPU에 대한 제약은 샘플 Bank of Sirius 애플리케이션에 가해지는 부하량과 직접적으로 연결됩니다. MARA 배포에는 Bank of Sirius에 부하를 생성하는 Locust가 포함되어 있으며, 사용자가 제어하는 사용자 수 설정과 새 사용자의 생성 속도가 포함됩니다.

시리우스 은행의 부하가 증가하면 나머지 시스템에도 영향을 미칩니다. 사용자 수나 생성 속도가 너무 높으면 MARA 성능이 저하되어 구성 요소가 충돌하거나 멈출 가능성이 높습니다. 이러한 동작을 유발하는 값은 사용 가능한 CPU에 따라 달라지지만, 요구 사항 에 지정된 용량 이상으로 배포하면 최대 64명의 사용자와 한 번에 16명의 사용자에 의해 생성된 부하를 처리할 수 있습니다.

MicroK8s에 MARA 배포

이제 배경 지식을 갖추었으니, MicroK8s에서 MARA를 세울 준비가 되었습니다!

요구 사항

  • Ubuntu 20.04(Focal) 이상을 실행하는 시스템(베어메탈 Linux 서버, 가상화 또는 클라우드)에서 루트 액세스(최소:

    • 20GB 디스크
    • 16GB 메모리
    • 4개의 CPU와 동일

  • MARA에 필요한 모든 라이브러리와 바이너리가 포함된 로컬 시스템의 Python 3 가상 환경입니다. Python 3이 아직 설치되지 않았다면 다음 명령을 실행하세요.

    $ sudo apt 업데이트 $ sudo apt 설치 -y python3-venv

  • NGINX Ingress Controller 송신에 할당할 MicroK8s의 통합 MetalLB 부하 분산 장치에 사용할 최소 하나의 여유 IPv4 주소가 필요합니다. 로컬호스트를 통해 Bank of Sirius 애플리케이션에 접속하는 경우, 사용 가능한 개인 ( RFC 1918 호환) 주소라면 모두 허용됩니다. 예를 들어, 네트워크가 192.168.100.0/24인 경우 10.10.10.10과 같은 주소를 사용할 수 있습니다.

  • 풀루미 계정과 액세스 토큰. 아직 없는 경우 MARA 배포 의 1단계 에서 생성합니다.

    Pulumi를 사용하면 상태 파일을 S3 호환 객체 저장소나 로컬 파일 시스템에 저장할 수 있지만, 이 글을 쓰는 시점에서는 MARA에서는 이를 지원하지 않습니다. 이런 제한은 MARA 또는 Pulumi의 향후 릴리스에서 제거될 예정입니다.

MicroK8s 설치 및 구성

  1. MicroK8s 설치:

    $ sudo snap install microk8s --classic microk8s (1.23/stable) v1.23.3 from Canonical✓ 설치됨

  2. microk8s 명령을 실행하는 데 필요한 권한을 설정합니다. 을 위한 <사용자 이름>, 귀하의 계정을 대체하십시오 뿌리 시스템에 대한 권한:

    $ sudo usermod -a -G microk8s <사용자 이름> $ sudo chown -f -R <사용자 이름> ~/.kube $ newgrp microk8s

  3. 새로운 권한이 적용되도록 루트 권한이 있는 계정에서 로그아웃했다가 다시 로그인하세요.

  4. DNS , 스토리지 , MetalLB 에 대한 MicroK8s 애드온을 활성화합니다.

    프롬프트에서 X . X . X . X ‑ X . X . X . Y 형태의 IP 주소 범위를 지정하여 다음을 나타냅니다.

    • 개인 IP 주소의 실제 범위(예:192.168.100.100-192.168.100.110 , 아래에 사용된 값)
    • 단일 개인 IP 주소(예:192.168.100.100-192.168.100.100 )
    $ microk8s enable dns storage metallb DNS 활성화 매니페스트 적용 ...
kubelet DNS 재시작이 활성화되었습니다. 기본 저장소 클래스 활성화 중...
저장소는 곧 사용 가능합니다. MetalLB 활성화 각 IP 주소 범위를 쉼표로 구분하여 입력합니다(예: '10.64.140.43-10.64.140.49,192.168.0.105-192.168.0.111'): 192.168.100.100-192.168.100.110
Metallb 매니페스트 적용 중 ...
MetalLB가 활성화되었습니다

  5. MicroK8s가 실행 중인지 확인하세요:

    $ microk8s 상태 microk8s가 고가용성을 실행 중입니다: 데이터 저장소 마스터 노드 없음: 127.0.0.1:19001 datastore 대기 노드: 없음 애드온: 활성화: dns # CoreDNS ha-cluster # 현재 노드에서 고가용성 구성 metallb # 쿠버네티스 클러스터용 로드밸런서 storage # 스토리지 클래스; 호스트 디렉토리에서 스토리지를 할당 ...

  6. 대부분의 유틸리티가 찾을 것으로 예상하는 파일( ~/.kube/config )에 MicroK8s 구성을 로드하고 디렉토리 및 파일에 권장되는 권한을 설정합니다.

    $ microk8s config > ~/.kube/config $ sudo chmod 0644 ~/.kube/config

MARA Repo 복제 및 MicroK8s 클러스터 설정

  1. MARA 저장소를 복제하고 Bank of Sirius 하위 모듈을 초기화합니다.

    $ git clone https://github.com/nginxinc/kic-reference-architectures.git $ cd kic-reference-architectures/ $ git 하위 모듈 업데이트 --init --recursive --remote

  2. 복제된 MARA 리포의 루트 디렉토리에서 작업합니다(이전 단계에서 해당 디렉토리를 변경했습니다). MicroK8s 클러스터에 대한 Python 가상 환경을 설정합니다.

    $ ./bin/setup_venv.sh

    이 명령은 긴 추적을 생성합니다. 오류가 있는 경우 MARA GitHub 저장소의 알려진 문제/주의 사항 섹션에서 제안 사항을 확인하세요.

  3. Python 가상 환경을 활성화합니다. 이 명령은 가상 환경을 사용하도록 PATH 및 기타 환경 변수를 설정합니다.

    $ 소스 ./pulumi/python/venv/bin/activate

  4. MARA 배포를 위해 MicroK8s 클러스터가 올바르게 구성되었는지 확인하세요.

    $ ./bin/testcap.sh 이 스크립트는 현재 활성화된 Kubernetes 구성 및 컨텍스트를 사용하여 현재의 Kubernetes 설치에서 테스트를 수행합니다.
모든 실패는 MARA를 실행하는 데 필요한 최소한의 기능 집합을 설치가 충족하지 않는다는 것을 나타내므로 조사해야 합니다. ... ==================================================================== | 모든 테스트에 통과했습니다! 이 시스템은 MARA를 배치하는 데 필요한 기본 요구 사항을 충족합니다. | | ==============================================================

MARA 배치

이 섹션에서 MARA를 배포하는 데 사용되는 start.sh 스크립트는 배포를 성공적으로 수행하기 위해 추가 작업이 필요한 옵션을 제공합니다. 단순화를 위해 여기서는 다음과 같은 기본 배포를 가정합니다.

  • 지원되는 다른 배포 옵션 대신 kubeconfig 파일을 사용합니다. 다른 옵션에 대한 자세한 내용은 GitHub 저장소의 시작 가이드를 참조하세요.
  • 우리가 MARA를 테스트한 NGINX 오픈 소스의 최신 버전을 사용합니다(반드시 최신 버전일 필요는 없습니다).
  • NGINX 오픈 소스 기반의 NGINX Ingress Controller를 사용합니다. NGINX Plus 기반의 NGINX Ingress Controller를 사용하려면 Kubernetes 클러스터의 F5 Docker 레지스트리에서 NGINX Plus 기반 이미지를 사용해야 합니다. 자세한 내용은 아래 3단계 의 첫 번째 공지사항을 참조하세요.
  • 단일 표준 Kubernetes 컨텍스트를 사용합니다. 3단계의 두 번째 공지사항을 확인하세요.

MicroK8s 클러스터에 MARA 배포:

  1. start.sh 스크립트를 실행합니다.

    아직 Pulumi를 사용하도록 워크스테이션을 구성하지 않은 경우 Pulumi에 로그인하라는 메시지가 표시되고(필요한 경우 계정 생성) Pulumi 계정과 연결된 API 토큰을 입력하라는 메시지가 표시됩니다.

    $ ./bin/start.sh [/home/ubuntu/kic-reference-architectures/bin/venv/bin]에 PATH 추가 로그인하여 Pulumi 스택을 관리하세요.
대체 로그인 옵션을 보려면 `pulumi login --help`를 실행하세요.
https://app.pulumi.com/account/tokens에서 액세스 토큰을 입력하세요.
또는 <ENTER>를 눌러 브라우저를 사용하여 로그인하세요. <토큰>

자세한 내용은 설명서를 읽어보세요.

  2. 배포 유형을 선택하고 프롬프트에 k를 입력하여 kubeconfig 파일로 배포를 빌드합니다. make 와 Docker가 설치되지 않았다는 경고는 무시하세요. 배포는 대신 레지스트리의 NGINX Ingress Controller 이미지를 사용합니다.

    AWS의 경우 a, kubeconfig의 경우 k를 입력하세요? k kubeconfig 시작 스크립트 make를 호출하는 중이 아닙니다. 소스에서 NGINX Kubernetes Ingress Controller를 빌드하려면 반드시 설치해야 합니다. docker가 설치되지 않았습니다. 소스에서 NGINX Kubernetes Ingress Controller를 빌드하려면 반드시 설치해야 합니다.

  3. 프롬프트에서, 생성할 Pulumi 스택의 이름을 지정합니다(여기서는 mara ). 이는 Pulumi 계정 내에서 고유해야 합니다.

    모든 프로젝트에서 사용할 Pulumi 스택의 이름을 입력하세요: mara 하위 모듈 소스를 찾았습니다. 모든 Pulumi 프로젝트에서 이 스택을 사용하도록 구성 중입니다: mara 스택 'mara'를 생성했습니다. 알림! 현재 kubeconfig를 통한 배포는 레지스트리에서 이미지를 가져오는 것만 지원합니다! NGINX Plus 저장소에 액세스하려면 JWT가 필요합니다. 루트의 extras 디렉토리에 jwt.token이라는 이름의 파일로 저장해야 합니다. 자세한 내용과 예시는 https://docs.nginx.com/nginx-ingress-controller/installation/using-the-jwt-token-docker-secret/에서 확인할 수 있습니다.

JWT를 찾을 수 없습니다. 플레이스홀더 매니페스트를 작성 중입니다. 알림! kubeconfig 파일을 사용하는 경우 Kubernetes에 제대로 연결되도록 환경이 구성되어 있는지 확인해야 합니다. 여러 개의 Kubernetes 컨텍스트(또는 사용자 정의 컨텍스트)가 있는 경우 이를 제거하고 간단한 ~/.kube/config 파일로 바꿔야 할 수도 있습니다. 이 문제는 향후 릴리스에서 해결될 예정입니다.

  4. 프롬프트에서 kubeconfig 파일의 전체 경로와 클러스터 이름을 지정합니다. 여기 있습니다 /집/<사용자 이름>/.kube/config 그리고 마이크로k8s-클러스터.

    kubeconfig 파일 값에 대한 절대 경로를 제공하세요: /집/<사용자 이름>/.kube/config
클러스터 이름
값을 제공하세요: 마이크로k8s-클러스터
쿠버네티스 클러스터에 연결 시도

  5. 다음 프롬프트에서 클러스터의 정규화된 도메인 이름(FQDN)을 지정하세요. 스크립트는 두 가지 목적으로 FQDN을 사용합니다. NGINX Ingress Controller를 구성하고 자체 서명된 인증서를 만드는 것입니다(두 번째 용도는 값이 IP 주소일 수 없음을 의미합니다). mara.example.com을 다른 FQDN으로 대체한 경우 다음 단계에서도 해당 FQDN을 사용해야 합니다.

    6. 배포 값에 대한 fqdn을 만듭니다: mara.example.com

  6. Grafana 관리자 비밀번호를 지정하세요:

    grafana 관리자 사용자의 비밀번호를 만드세요. 이 비밀번호는 Grafana 대시보드에 접속하는 데 사용됩니다. 셸 특수 문자가 없는 영숫자 문자열이어야 하며, 현재 Pulumi 비밀의 제한으로 인해 일반 텍스트로 표시됩니다. Grafana 대시보드에 액세스하려면 이 비밀번호가 필요합니다. 값: <비밀번호>

    7. 설치 과정의 흔적이 나타나며 각 단계에 대한 다음 정보가 표시됩니다.

    • 단계에서 수행된 주요 작업을 설명하는 배너(예: Logstore는 Elasticsearch 배포 시작을 알립니다)
    • Pulumi가 수행할 작업 목록
    • 각 Pulumi 작업에 대한 실시간 상태 표시기
    • 예를 들어 Pulumi 및 MARA에서 생성된 진단은 정의된 호스트 이름 및 IP 주소입니다.
    • 영향을 받는 자원의 수
    • 경과 시간

    마지막 단계(Bank of Sirius의 경우)가 완료되면 추적은 MetalLB가 NGINX Ingress Controller에 할당한 IP 주소를 보고합니다(여기서는192.168.100.100 ) 및 배포를 위해 선택한 FQDN(여기서는 mara.example.com )과 배포에 대한 기타 정보가 포함됩니다.

    시작 프로세스가 성공적으로 완료되었습니다
다음 단계:
1. Ingress Controller의 IP 주소(192.168.100.100)를 FQDN(mara.example.com)으로 매핑합니다.
2. ./bin/test-forward.sh 프로그램을 사용하여 관리 도구에 연결하는 데 사용할 수 있는 터널을 설정합니다.
3. kubectl, k9s 또는 Kubernetes 대시보드를 사용하여 배포를 탐색하세요.

정의된 비밀번호를 포함하여 구성 옵션을 검토하려면 다음 명령을 통해 pulumi 비밀에 액세스할 수 있습니다.

기본 구성: pulumi config -C /jenkins/workspace/jaytest/bin/../pulumi/python/config

Bank of Sirius(예시 애플리케이션) 구성: pulumi config -C /jenkins/workspace/jaytest/bin/../pulumi/python/kubernetes/applications/sirius

K8 로드밸런서 IP: kubectl get services --namespace nginx-ingress

자세한 내용은 github 저장소의 설명서를 참조하세요.

  7. 이전 단계에서 보고된 FQDN과 IP 주소 간의 매핑을 FQDN을 확인하는 데 사용하는 도구(로컬 /etc/hosts 파일 또는 DNS 서버 등)에서 만듭니다.

  8. MARA 배포 요청이 성공했는지 확인합니다. -k 옵션을 포함하면 curl이 자체 서명된 인증서를 허용합니다. 인증서에 대한 자세한 정보를 표시하려면 -v 옵션을 추가하세요.

    $ curl -k -I https://mara.example.com HTTP/1.1 200 OK 서버: nginx/1.21.5 날짜: 일 , DD 월 YYYY hh:mm:ss TZ 콘텐츠 유형: text/html; 문자 집합=utf-8 콘텐츠 길이: 7016 연결: keep-alive

  9. 브라우저에서 https://mara.example.com 으로 이동하여 Bank of Sirius 웹사이트를 표시합니다. 이 글을 쓰는 시점에서는 많은 브라우저(Firefox와 Safari 포함)에서 자체 서명된 인증서를 이용하여 사이트에 대한 경고를 안전하게 클릭할 수 있습니다. Chrome을 사용하지 않는 것이 좋습니다. 최근 보안 변경으로 인해 사이트에 접속하지 못할 가능성이 있습니다.

  10. test-forward.sh 스크립트를 실행하여 Kubernetes 포트 포워딩을 설정하여 MARA 관리 제품군의 도구( Elasticsearch , Grafana , Kibana , Locust , Prometheus) 에 액세스할 수 있습니다. 스크립트는 적절한 서비스 이름을 결정하고 kubectl 명령을 실행하여 이를 로컬 포트로 전달합니다.

    메모: 포트 포워딩이 제대로 작동하려면 브라우저가 이 명령을 실행하는 명령 셸과 동일한 시스템에서 실행되어야 합니다. 그렇지 않은 경우(예를 들어 가상화 환경을 사용하는 경우) 명령은 성공한 것처럼 보이지만 포트 포워딩은 실제로 작동하지 않습니다. 자세한 내용은 GitHub 저장소에서 MARA의 관리 도구 액세스를 참조하세요.

    $ ./bin/test-forward.sh 연결 세부 정보 ====================================== Kibana: http://localhost:5601 Grafana: http://localhost:3000 Locust: http://localhost:8089 Prometheus: http://localhost:9090 Elasticsearch: http://localhost:9200 ===================================== Ctrl-C를 실행하여 종료합니다.

요약

다 됐어요! 이러한 지침을 따르면 약 20분 내에 사용자 환경에서 작동하는 MARA 배포가 시작됩니다. 이 시점에서 다른 Kubernetes 애플리케이션과 마찬가지로 Bank of Sirius 애플리케이션과 상호작용할 수 있습니다. 좋은 시작점은 내장된 관찰 도구를 사용하여 Locust로 서로 다른 양의 부하를 생성할 때 환경이 어떻게 작동하는지 테스트하는 것입니다.

우리의 목표는 가능한 한 많은 Kubernetes 사용자에게 MARA를 최대한 유용하게 만드는 것입니다. 일부 구성 요소에 대한 선택이 마음에 들지 않으신가요? 공유하고 싶다면 구성 요소를 대체하고 풀 리퀘스트를 열어보세요 . 또한, 저희 저장소의 이슈 및 토론 페이지에서 생각을 공유하고 질문을 올려주세요. 의심스러운 가정에 대한 질문도 포함됩니다.

관련 게시물

이 게시물은 시리즈의 일부입니다. 시간이 지남에 따라 MARA에 기능을 추가함에 따라 블로그에 세부 정보를 게시하고 있습니다.

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."