Kubernetes에서 실행되는 애플리케이션 개발자를 위한 도구

운영에 대한 현대적인 접근 방식은 많은 시급한 비즈니스 문제를 해결합니다. 컨테이너와 오케스트레이터를 사용하면 복잡한 프로젝트를 쉽게 확장하고 새 버전 출시를 단순화하며 안정성을 높일 수 있지만 동시에 개발자에게 추가적인 문제를 야기합니다. 프로그래머는 우선 자신의 코드(아키텍처, 품질, 성능, 우아함)에 관심을 가집니다. Kubernetes에서 코드가 어떻게 작동하는지, 최소한의 변경만 한 후에 코드를 테스트하고 디버깅하는 방법은 중요하지 않습니다. 따라서 Kubernetes용 도구가 활발히 개발되어 가장 "구식" 개발자의 문제를 해결하고 그들이 중요한 것에 집중할 수 있도록 하는 것도 매우 자연스러운 일입니다.

이 리뷰는 Kubernetes 클러스터의 pod'ax에서 코드가 실행되는 프로그래머의 삶을 더 쉽게 만들어 주는 일부 도구에 대한 간략한 정보를 제공합니다.

간단한 도우미

Kubectl 디버그

• 최종선 : 컨테이너를 Pod에 추가하고 그 안에서 무슨 일이 일어나는지 확인하세요..
• GitHub의.
• 간략한 GH 통계: 별 715개, 커밋 54개, 기여자 9명.
• 언어: 가세요.
• 라이센스: 아파치 라이센스 2.0.

kubectl용 이 플러그인을 사용하면 관심 있는 포드 내부에 추가 컨테이너를 생성할 수 있으며, 이 컨테이너는 다른 컨테이너와 프로세스 네임스페이스를 공유합니다. 여기서는 Pod의 작업을 디버그할 수 있습니다. 즉, 네트워크를 확인하고, 네트워크 트래픽을 듣고, 관심 있는 프로세스를 추적하는 등의 작업을 수행할 수 있습니다.

다음을 실행하여 프로세스 컨테이너로 전환할 수도 있습니다. chroot /proc/PID/root - 이는 매니페스트에 설정된 컨테이너에서 루트 셸을 가져와야 할 때 매우 편리할 수 있습니다. securityContext.runAs.

이 도구는 간단하고 효과적이므로 모든 개발자에게 유용할 수 있습니다. 우리는 그것에 대해 더 많이 썼습니다. 별도의 기사.

텔레프레즌스

• 최종선 : 응용 프로그램을 컴퓨터로 전송하십시오. 로컬에서 개발 및 디버그.
• 웹 사이트; GitHub의.
• 간략한 GH 통계: 별 2131개, 커밋 2712개, 기여자 33명.
• 언어: 파이썬.
• 라이센스: 아파치 라이센스 2.0.

이 스냅인의 아이디어는 로컬 사용자 컴퓨터에서 응용 프로그램이 포함된 컨테이너를 시작하고 클러스터의 모든 트래픽을 프록시로 프록시하는 것입니다. 이 접근 방식을 사용하면 즐겨 사용하는 IDE에서 파일을 간단히 편집하여 로컬로 개발할 수 있으며 결과를 즉시 사용할 수 있습니다.

로컬로 실행하면 편집이 편리하고 즉각적인 결과를 얻을 수 있으며 일반적인 방식으로 애플리케이션을 디버그할 수 있다는 장점이 있습니다. 단점은 연결 속도를 요구한다는 것인데, 이는 RPS와 트래픽이 상당히 높은 애플리케이션으로 작업해야 할 때 특히 두드러집니다. 또한 Telepresence는 Windows에서 볼륨 마운트에 문제가 있는데, 이는 이 OS에 익숙한 개발자에게 결정적인 제한이 될 수 있습니다.

우리는 이미 Telepresence 사용 경험을 공유했습니다. 여기에.

Ksync

• 최종선 : 클러스터의 컨테이너와 코드의 거의 즉각적인 동기화.
• GitHub의.
• 간략한 GH 통계: 별 555개, 커밋 362개, 기여자 11명.
• 언어: 가세요.
• 라이센스: 아파치 라이센스 2.0.

이 유틸리티를 사용하면 로컬 디렉터리의 내용을 클러스터에서 실행 중인 컨테이너의 디렉터리와 동기화할 수 있습니다. 이러한 도구는 실행 중인 컨테이너에 코드를 전달하는 것이 주요 문제인 스크립팅 프로그래밍 언어 개발자에게 적합합니다. Ksync는 이러한 두통을 완화하도록 설계되었습니다.

명령으로 한 번 초기화되면 ksync init 선택한 컨테이너의 파일 시스템 상태를 모니터링하는 데 사용되는 DaemonSet가 클러스터에 생성됩니다. 개발자는 자신의 로컬 컴퓨터에서 다음 명령을 실행합니다. ksync watch구성을 모니터링하고 실행하는 syncthing, 파일을 클러스터와 직접 동기화합니다.

남은 것은 ksync에게 무엇을 무엇과 동기화할지 지시하는 것입니다. 예를 들어 다음 명령은 다음과 같습니다.

ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/

...라는 이름의 감시자를 생성합니다. myproject라벨이 있는 포드를 검색합니다. app=backend 로컬 디렉터리를 동기화해 보세요. /home/user/myproject/ 카탈로그 포함 /var/www/myproject/ 라는 컨테이너에서 php.

우리 경험에서 나온 ksync 문제와 참고 사항:

• Kubernetes 클러스터 노드에서 사용해야 합니다. overlay2 Docker용 스토리지 드라이버로 사용됩니다. 이 유틸리티는 다른 유틸리티와 함께 ​​작동하지 않습니다.
• Windows를 클라이언트 OS로 사용하는 경우 파일 시스템 감시자가 올바르게 작동하지 않을 수 있습니다. 이 버그는 많은 수의 중첩된 파일과 디렉터리가 있는 대규모 디렉터리에서 작업할 때 발견되었습니다. 우리는 만들었습니다 관련 문제 동기화 프로젝트를 진행 중인데 아직(XNUMX월 초 이후) 진전이 없습니다.
• 파일 사용 .stignore 동기화할 필요가 없는 경로나 파일 패턴을 지정하려면(예: 디렉터리 app/cache и .git).
• 기본적으로 ksync는 파일이 변경될 때마다 컨테이너를 다시 시작합니다. Node.js의 경우 이는 편리하지만 PHP의 경우 전혀 필요하지 않습니다. opcache를 끄고 플래그를 사용하는 것이 좋습니다 --reload=false.
• 구성은 항상 다음에서 수정될 수 있습니다. $HOME/.ksync/ksync.yaml.

스쿼시

• 최종선 : 클러스터에서 직접 프로세스 디버그.
• GitHub의.
• 간략한 GH 통계: 별 1154개, 커밋 279개, 기여자 23명.
• 언어: 가세요.
• 라이센스: 아파치 라이센스 2.0.

이 도구는 Pod에서 직접 프로세스를 디버깅하도록 설계되었습니다. 이 유틸리티는 간단하며 대화형으로 원하는 디버거를 선택할 수 있습니다. (아래 참조) 및 네임스페이스 + 포드(이 과정에서 사용자가 개입해야 함) 현재 지원되는 것:

• delve - Go 애플리케이션용;
• GDB - 대상 원격 + 포트 전달을 통해;
• Java 애플리케이션 디버깅을 위한 JDWP 포트 전달.

IDE 측에서는 VScode에서만 지원이 가능합니다. 확장) 그러나 금년(2019년) 계획에는 Eclipse와 Intellij가 포함됩니다.

프로세스를 디버깅하기 위해 Squash는 클러스터 노드에서 권한 있는 컨테이너를 실행하므로 먼저 기능을 숙지해야 합니다. 안전 모드 보안 문제를 피하기 위해.

완벽한 솔루션

개발자의 많은 요구 사항을 즉시 충족하도록 설계된 보다 "대규모" 프로젝트인 중포로 넘어가겠습니다.

NB: 물론 이 목록에는 오픈 소스 유틸리티를 위한 공간이 있습니다. 워프 (이전에는 dapp으로 알려짐). 그러나 우리는 이미 그것에 대해 여러 번 작성하고 이야기했기 때문에 리뷰에 포함하지 않기로 결정했습니다. 그 기능에 대해 더 잘 알고 싶다면 보고서를 읽고 듣는 것을 권장합니다.werf는 Kubernetes의 CI/CD용 도구입니다.".

데브스페이스

• 최종선 : Kubernetes에서 작업을 시작하고 싶지만 정글에 깊이 들어가고 싶지 않은 사람들을 위한.
• GitHub의.
• 간략한 GH 통계: 별 630개, 커밋 1912개, 기여자 13명.
• 언어: 가세요.
• 라이센스: 아파치 라이센스 2.0.

팀 개발을 위해 Kubernetes와 함께 관리형 클러스터를 제공하는 동명의 회사의 솔루션입니다. 이 유틸리티는 상업용 클러스터용으로 만들어졌지만 다른 클러스터와도 잘 작동합니다.

명령을 실행할 때 devspace init 프로젝트 카탈로그에서 다음 사항이 대화형으로 제공됩니다.

• 작동 중인 Kubernetes 클러스터를 선택하고,
• 기존 사용 Dockerfile (또는 새 것을 생성하여) 이를 기반으로 컨테이너를 생성하고,
• 컨테이너 이미지 등을 저장할 저장소를 선택합니다.

이러한 모든 준비 단계가 끝나면 다음 명령을 실행하여 개발을 시작할 수 있습니다. devspace dev. 컨테이너를 빌드하고, 리포지토리에 업로드하고, 클러스터에 배포를 롤아웃하고, 로컬 디렉터리와 컨테이너의 포트 전달 및 동기화를 시작합니다.

선택적으로 터미널을 컨테이너로 이동하라는 메시지가 표시됩니다. 실제로 컨테이너는 sleep 명령으로 시작하고 실제 테스트를 위해서는 애플리케이션을 수동으로 시작해야 하기 때문에 거부해서는 안 됩니다.

마지막으로 팀은 devspace deploy 애플리케이션과 관련 인프라를 클러스터에 롤아웃한 후 모든 것이 전투 모드에서 작동하기 시작합니다.

모든 프로젝트 구성은 파일에 저장됩니다. devspace.yaml. 개발 환경 설정 외에도 표준 Kubernetes 매니페스트와 유사하지만 크게 단순화된 인프라에 대한 설명도 찾을 수 있습니다.

DevSpace 작업의 아키텍처 및 주요 단계

또한 사전 정의된 구성 요소(예: MySQL DBMS) 또는 Helm 차트를 프로젝트에 쉽게 추가할 수 있습니다. 자세히 알아보기 선적 서류 비치 - 복잡하지 않아요.

비계

• 웹 사이트; GitHub의.
• 간략한 GH 통계: 별 7423개, 커밋 4173개, 기여자 136명.
• 언어: 가세요.
• 라이센스: 아파치 라이센스 2.0.

Google의 이 유틸리티는 코드가 Kubernetes 클러스터에서 실행되는 개발자의 모든 요구 사항을 충족한다고 주장합니다. 사용 시작은 devspace만큼 쉽지 않습니다. 상호 작용 없음, 언어 감지 및 자동 생성 Dockerfile 그들은 여기서 당신에게 그것을 제공하지 않을 것입니다.

하지만 이것이 두렵지 않다면 Skaffold를 통해 수행할 수 있는 작업은 다음과 같습니다.

• 소스 코드 변경 사항을 추적합니다.
• 조립이 필요하지 않은 경우 포드 컨테이너와 동기화하세요.
• 언어가 해석되는 경우 코드로 컨테이너를 수집하거나 아티팩트를 컴파일하여 컨테이너에 패키징합니다.
• 결과 이미지는 다음을 사용하여 자동으로 확인됩니다. 컨테이너 구조 테스트.
• Docker 레지스트리에 이미지에 태그를 지정하고 업로드합니다.
• kubectl, Helm 또는 kustomize를 사용하여 클러스터에 애플리케이션을 배포합니다.
• 포트 포워딩을 수행합니다.
• Java, Node.js, Python으로 작성된 애플리케이션을 디버그합니다.

다양한 변형의 워크플로가 파일에 선언적으로 설명되어 있습니다. skaffold.yaml. 프로젝트의 경우 어셈블리 및 배포 단계를 부분적으로 또는 완전히 변경할 수 있는 여러 프로필을 정의할 수도 있습니다. 예를 들어 개발의 경우 개발자에게 편리한 기본 이미지를 지정하고 스테이징 및 프로덕션을 위해 최소한의 이미지를 지정합니다(+ 사용 securityContext 컨테이너를 수정하거나 애플리케이션이 배포될 클러스터를 재정의할 수 있습니다.

Docker 컨테이너는 로컬 또는 원격으로 구축할 수 있습니다. 구글 클라우드 빌드 또는 다음을 사용하는 클러스터에서 카니코. Bazel 및 Jib Maven/Gradle도 지원됩니다. 태그 지정을 위해 Skaffold는 git 커밋 해시, 날짜/시간, 소스의 sha256 합계 등 다양한 전략을 지원합니다.

이와 별도로 컨테이너 테스트 가능성에 주목할 가치가 있습니다. 이미 언급한 컨테이너 구조 테스트 프레임워크는 다음과 같은 검증 방법을 제공합니다.

• 종료 상태를 추적하고 명령의 텍스트 출력을 확인하여 컨테이너 컨텍스트에서 명령을 실행합니다.
• 컨테이너에 파일이 있는지 확인하고 지정된 속성과 일치합니다.
• 정규식을 사용하여 파일 내용을 제어합니다.
• 이미지 메타데이터 확인(ENV, ENTRYPOINT, VOLUMES 등).
• 라이센스 호환성을 확인하는 중입니다.

컨테이너와 파일 동기화는 가장 최적의 방식으로 수행되지 않습니다. Skaffold는 단순히 소스가 포함된 아카이브를 생성하고 복사한 후 컨테이너에 압축을 풉니다(tar를 설치해야 함). 따라서 주요 작업이 코드 동기화라면 전문 솔루션(ksync)을 찾는 것이 좋습니다.

Skaffold 운영의 주요 단계

일반적으로 이 도구는 Kubernetes 매니페스트에서 추상화하는 것을 허용하지 않으며 상호 작용이 없으므로 마스터하기 어려울 수 있습니다. 그러나 이것은 또한 장점입니다. 행동의 자유가 더 커집니다.

정원

• 웹 사이트; GitHub의.
• 간략한 GH 통계: 별 1063개, 커밋 1927개, 기여자 17명.
• 언어: TypeScript (프로젝트를 여러 구성 요소로 분할할 계획이며 그 중 일부는 Go에 포함될 예정이며 TypeScript/JavaScript 및 Go에서 추가 기능을 생성하기 위한 SDK도 만들 예정입니다).
• 라이센스: 아파치 라이센스 2.0.

Skaffold와 마찬가지로 Garden은 애플리케이션 코드를 K8s 클러스터에 전달하는 프로세스를 자동화하는 것을 목표로 합니다. 이렇게 하려면 먼저 YAML 파일에서 프로젝트 구조를 설명한 후 다음 명령을 실행해야 합니다. garden dev. 그녀는 모든 마술을 할 것입니다:

• 프로젝트의 다양한 부분이 포함된 컨테이너를 수집하세요.
• 설명된 경우 통합 및 단위 테스트를 수행합니다.
• 모든 프로젝트 구성 요소를 클러스터에 롤아웃합니다.
• 소스 코드가 변경되면 전체 파이프라인이 다시 시작됩니다.

이 도구를 사용하는 주요 초점은 개발 팀과 원격 클러스터를 공유하는 것입니다. 이 경우 구축 및 테스트 단계 중 일부가 이미 완료되었다면 Garden에서 캐시된 결과를 사용할 수 있으므로 전체 프로세스 속도가 크게 빨라집니다.

프로젝트 모듈은 컨테이너, Maven 컨테이너, Helm 차트, 매니페스트일 수 있습니다. kubectl apply 또는 OpenFaaS 기능도 있습니다. 또한 원격 Git 저장소에서 모든 모듈을 가져올 수 있습니다. 모듈은 서비스, 작업 및 테스트를 정의할 수도 정의하지 않을 수도 있습니다. 서비스와 작업은 종속성을 가질 수 있으므로 특정 서비스의 배포 순서를 결정하고 작업 및 테스트의 시작을 구성할 수 있습니다.

Garden은 사용자에게 아름다운 대시보드를 제공합니다(현재 실험적 상태)에는 구성 요소, 조립 순서, 작업 및 테스트 실행, 연결 및 종속성 등 프로젝트 그래프가 표시됩니다. 브라우저에서 바로 모든 프로젝트 구성 요소의 로그를 보고 특정 구성 요소가 HTTP를 통해 출력하는 내용을 확인할 수 있습니다(물론 수신 리소스가 선언된 경우).

정원용 패널

또한 이 도구에는 스크립트 변경 사항을 클러스터의 컨테이너와 동기화하는 핫 리로드 모드도 있어 애플리케이션 디버깅 프로세스의 속도를 크게 높입니다. 정원에는 좋은 것이 있습니다 문서 그리고 나쁘지 않다 일련의 예시, 빠르게 익숙해지고 사용할 수 있습니다. 그건 그렇고, 최근에 우리는 출판했습니다 기사 번역 저자로부터.

결론

물론 Kubernetes에서 애플리케이션을 개발하고 디버깅하기 위한 도구 목록은 이에 국한되지 않습니다. 별도의 기사는 아니더라도 최소한 언급할 가치가 있는 훨씬 더 유용하고 실용적인 유틸리티가 많이 있습니다. 무엇을 사용하고 있는지, 어떤 문제가 발생했는지, 어떻게 해결했는지 알려주세요!

PS

블로그에서도 읽어보세요.

• «werf - Kubernetes의 CI/CD용 도구(개요 및 비디오 보고서)";
• «Garden v0.10.0: 노트북에는 Kubernetes가 필요하지 않습니다.";
• «Kubernetes 팁 및 요령: 로컬 개발 및 Telepresence 정보";
• «Kubernetes 포드에서 디버깅을 위한 kubectl-debug 플러그인".

출처 : habr.com