werf - Kubernetes의 CI/CD용 도구(개요 및 비디오 보고서)

27월 2019일 페스티벌의 일환으로 열린 DevOpsConf XNUMX 컨퍼런스 메인 홀에서 RIT++ 2019, "지속적 전달" 섹션의 일부로 "werf - Kubernetes의 CI/CD용 도구"라는 보고서가 제공되었습니다. 그것에 대해 이야기합니다 Kubernetes에 배포할 때 모두가 직면하는 문제와 과제, 즉시 눈에 띄지 않는 뉘앙스에 대해서도 설명합니다. 가능한 솔루션을 분석하여 이것이 오픈 소스 도구에서 어떻게 구현되는지 보여줍니다. 워프.

프레젠테이션 이후 우리의 유틸리티(이전에는 dapp으로 알려짐)는 다음과 같은 역사적인 이정표에 도달했습니다. GitHub의 별 1000개 — 점점 늘어나는 사용자 커뮤니티가 많은 DevOps 엔지니어의 삶을 더 쉽게 만들어주기를 바랍니다.

그래서, 우리는 제시 보고서 영상 (~47분, 기사보다 훨씬 더 유익함) 및 텍스트 형식의 주요 발췌문입니다. 가다!

Kubernetes에 코드 제공

강연은 더 이상 werf에 관한 것이 아니라 Kubernetes의 CI/CD에 관한 것입니다. 이는 우리 소프트웨어가 Docker 컨테이너에 패키지되어 있음을 의미합니다. (내가 이 얘기를 했었는데 2016년 보고서), K8은 프로덕션 환경에서 실행하는 데 사용됩니다. (이에 대한 자세한 내용은 2017 년).

Kubernetes에서 전달은 어떤 모습인가요?

• 빌드를 위한 코드와 지침이 포함된 Git 저장소가 있습니다. 애플리케이션은 Docker 이미지에 내장되어 Docker 레지스트리에 게시됩니다.
• 동일한 저장소에는 애플리케이션을 배포하고 실행하는 방법에 대한 지침도 포함되어 있습니다. 배포 단계에서 이러한 지침은 Kubernetes로 전송되며, Kubernetes는 레지스트리에서 원하는 이미지를 받아 실행합니다.
• 또한 일반적으로 테스트가 있습니다. 이들 중 일부는 이미지를 게시할 때 수행할 수 있습니다. 또한 (동일한 지침에 따라) 애플리케이션 복사본을 별도의 K8s 네임스페이스 또는 별도의 클러스터에 배포하고 그곳에서 테스트를 실행할 수도 있습니다.
• 마지막으로 Git(또는 버튼 클릭)에서 이벤트를 수신하고 지정된 모든 단계(빌드, 게시, 배포, 테스트)를 호출하는 CI 시스템이 필요합니다.

여기에는 몇 가지 중요한 참고 사항이 있습니다.

1. 우리는 불변의 인프라를 갖고 있기 때문에 (불변 인프라), 모든 단계(스테이징, 프로덕션 등)에서 사용되는 애플리케이션 이미지, 하나쯤은 있어야 해. 나는 이것에 대해 더 자세히 그리고 예를 들어 이야기했습니다. 여기에.
2. 우리는 코드 접근 방식으로 인프라를 따르기 때문에 (IAC), 애플리케이션 코드, 조립 및 실행 지침은 다음과 같아야 합니다. 정확히 하나의 저장소에. 이에 대한 자세한 내용은 다음을 참조하세요. 같은 보고서.
3. 배송 체인 (배달) 우리는 일반적으로 다음과 같이 봅니다. 애플리케이션이 조립되고, 테스트되고, 출시되었습니다. (출시 단계) 그게 다입니다. 배송이 이루어졌습니다. 하지만 실제로 사용자는 당신이 출시한 것을 얻습니다. 아니 그런 다음 당신이 그것을 프로덕션에 전달했을 때 그가 거기에 갈 수 있었고 이 프로덕션이 작동했을 때. 그래서 배송 체인이 끝난다고 생각해요 운영 단계에서만 (운영)또는 더 정확하게는 코드가 프로덕션에서 제거된 순간에도 마찬가지입니다(새 코드로 교체).

위의 Kubernetes 전달 체계로 돌아가 보겠습니다. 이는 우리뿐만 아니라 말 그대로 이 문제를 다루는 모든 사람이 발명한 것입니다. 실제로 이 패턴은 이제 GitOps라고 불립니다. (용어와 그 뒤에 숨은 아이디어에 대해 자세히 알아볼 수 있습니다. 여기에). 계획의 단계를 살펴 보겠습니다.

빌드 단계

모두가 Dockerfile을 작성하고 실행하는 방법을 알고 있는 2019년에는 Docker 이미지 구축에 대해 이야기할 수 있을 것 같습니다. docker build?.. 제가 주목하고 싶은 뉘앙스는 다음과 같습니다.

1. 이미지 무게 중요하므로 사용하세요 다단식의작업에 실제로 필요한 애플리케이션만 이미지에 남겨 두는 것입니다.
2. 레이어 수 체인을 결합하여 최소화해야 합니다. RUN-의미에 따라 명령합니다.
3. 그러나 이는 문제를 추가합니다. 디버깅, 어셈블리가 충돌하면 문제를 일으킨 체인에서 올바른 명령을 찾아야 하기 때문입니다.
4. 조립 속도 변경 사항을 신속하게 적용하고 결과를 확인하고 싶기 때문에 중요합니다. 예를 들어, 애플리케이션을 빌드할 때마다 언어 라이브러리의 종속성을 다시 빌드하고 싶지는 않습니다.
5. 종종 하나의 Git 저장소에서 필요한 경우가 있습니다. 많은 이미지이는 Dockerfile 세트(또는 하나의 파일에 명명된 단계)와 순차적 어셈블리가 포함된 Bash 스크립트로 해결될 수 있습니다.

이는 모두가 직면하는 빙산의 일각에 불과했습니다. 그러나 특히 다음과 같은 다른 문제도 있습니다.

1. 종종 조립 단계에서 무언가가 필요합니다. 산 (예를 들어, 타사 디렉터리에 apt와 같은 명령 결과를 캐시합니다.)
2. 우리는 원한다 책임감있는 쉘에 쓰는 대신.
3. 우리는 원한다 Docker 없이 빌드 (컨테이너를 실행할 수 있는 Kubernetes 클러스터가 이미 있는데 이를 위해 모든 것을 구성해야 하는 추가 가상 머신이 필요한 이유는 무엇입니까?)
4. 병렬 조립, 이는 다양한 방식으로 이해될 수 있습니다. Dockerfile의 다른 명령(다단계가 사용되는 경우), 동일한 저장소의 여러 커밋, 여러 Dockerfile.
5. 분산 어셈블리: 우리는 "일시적인" 항목을 포드에 수집하려고 합니다. 캐시가 사라지므로 별도로 어딘가에 저장해야 합니다.
6. 드디어 욕망의 정점에 이름을 붙였다 자동 마법: 저장소에 가서 몇 가지 명령을 입력하고 올바르게 수행하는 방법과 작업에 대한 이해를 바탕으로 조립된 기성 이미지를 얻는 것이 이상적입니다. 그러나 개인적으로 모든 뉘앙스가 이런 식으로 예측될 수 있는지 확신하지 못합니다.

프로젝트는 다음과 같습니다.

• 모비/빌드킷 — 이러한 모든 문제를 해결하려고 노력하는 Docker Inc(현재 Docker 버전에 이미 통합되어 있음)의 빌더입니다.
• 카니코 — Docker 없이 빌드할 수 있게 해주는 Google의 빌더입니다.
• Buildpacks.io — 자동 마법을 만들려는 CNCF의 시도, 특히 레이어에 대한 리베이스를 사용한 흥미로운 솔루션입니다.
• 그리고 다음과 같은 다른 유틸리티들도 있습니다. Buildah, 정품 도구/img...

...GitHub에 얼마나 많은 별이 있는지 살펴보세요. 즉, 한편으로는 docker build 존재하고 무언가를 할 수 있지만 실제로는 문제가 완전히 해결되지 않았습니다 - 이에 대한 증거는 각각 문제의 일부를 해결하는 대체 수집가의 병행 개발입니다.

Werf에서 조립

그래서 우리는 워프 (이전 유명한 dapp처럼요) — 우리가 수년 동안 만들어온 Flant 회사의 오픈 소스 유틸리티입니다. 모든 것은 5년 전 Dockerfiles 어셈블리를 최적화하는 Bash 스크립트로 시작되었으며 지난 3년 동안 자체 Git 저장소가 있는 하나의 프로젝트 프레임워크 내에서 본격적인 개발이 수행되었습니다. (처음에는 Ruby에서, 그 다음에는 다시 썼다 Go, 동시에 이름이 변경됨). werf에서는 어떤 어셈블리 문제가 해결됩니까?

파란색으로 표시된 문제는 이미 구현되었으며, 병렬 빌드는 동일한 호스트 내에서 수행되었으며, 노란색으로 표시된 문제는 여름 말까지 완료될 예정입니다.

등록소에 게시되는 단계(게시)

우리는 전화를 걸었습니다 docker push... - 이미지를 레지스트리에 업로드할 때 어려운 점은 무엇입니까? 그러면 "이미지에 어떤 태그를 붙여야 할까요?"라는 질문이 생깁니다. 그것은 우리가 가지고 있는 이유로 발생합니다. 깃플로우 (또는 다른 Git 전략) 및 Kubernetes와 관련이 있으며 업계에서는 Kubernetes에서 일어나는 일이 Git에서 일어나는 일을 따르도록 노력하고 있습니다. 결국 Git은 우리의 유일한 정보 소스입니다.

그게 뭐가 그렇게 힘든데? 재현성 보장: 본질적으로 불변인 Git의 커밋에서 (불변), 동일하게 유지되어야 하는 Docker 이미지로 변환됩니다.

우리에게도 중요해요 원산지를 결정하다, Kubernetes에서 실행되는 애플리케이션이 어떤 커밋에서 빌드되었는지 이해하고 싶기 때문입니다(그런 다음 비교 및 ​​유사한 작업을 수행할 수 있습니다).

태그 지정 전략

첫 번째는 간단해요 자식 태그. 태그가 지정된 이미지가 있는 레지스트리가 있습니다. 1.0. Kubernetes에는 이 이미지가 업로드되는 단계와 프로덕션이 있습니다. Git에서는 커밋을 하고 어느 시점에는 태그를 지정합니다. 2.0. 저장소의 지침에 따라 이를 수집하고 태그와 함께 레지스트리에 배치합니다. 2.0. 우리는 이를 무대에 출시하고 모든 것이 정상이면 프로덕션에 적용합니다.

이 접근 방식의 문제점은 먼저 태그를 넣은 다음 테스트하고 출시한다는 것입니다. 왜? 첫째, 이는 단순히 비논리적입니다. 아직 테스트도 하지 않은 소프트웨어 버전을 출시하고 있습니다(확인하려면 태그를 넣어야 하기 때문에 달리 할 수는 없습니다). 둘째, 이 경로는 Gitflow와 호환되지 않습니다.

두 번째 옵션 - git 커밋 + 태그. 마스터 브랜치에는 태그가 있습니다 1.0; 레지스트리에 - 프로덕션에 배포된 이미지입니다. 또한 Kubernetes 클러스터에는 미리보기 및 스테이징 윤곽이 있습니다. 다음으로 Gitflow: 개발을 위한 메인 브랜치(develop) 새로운 기능을 만들어 식별자를 사용한 커밋을 생성합니다. #c1. 우리는 이 식별자를 사용하여 이를 수집하고 레지스트리에 게시합니다(#c1). 동일한 식별자를 사용하여 미리보기로 출시합니다. 커밋에도 동일한 작업을 수행합니다. #c2 и #c3.

기능이 충분하다는 것을 깨달았을 때 우리는 모든 것을 안정화하기 시작합니다. Git에서 브랜치 만들기 release_1.1 (베이스에 #c3 으로 develop). 이 릴리스를 수집할 필요가 없습니다. 왜냐하면... 이는 이전 단계에서 수행되었습니다. 따라서 간단히 스테이징으로 롤아웃할 수 있습니다. 우리는 버그를 수정합니다 #c4 마찬가지로 스테이징으로 롤아웃합니다. 동시에, 개발이 진행 중입니다. develop, 주기적으로 변경 사항을 가져옵니다. release_1.1. 어느 시점에서 우리는 컴파일되어 스테이징에 업로드된 커밋을 얻게 되는데, 이는 만족스럽습니다(#c25).

그런 다음 릴리스 브랜치를 (빨리 감기로) 병합합니다(release_1.1) 마스터에서. 이 커밋에 새 버전이 포함된 태그를 추가합니다(1.1). 하지만 이 이미지는 이미 레지스트리에 수집되어 있으므로 다시 수집하지 않으려면 기존 이미지에 두 번째 태그를 추가하기만 하면 됩니다(이제 레지스트리에 태그가 있습니다). #c25 и 1.1). 그런 다음 이를 프로덕션에 출시합니다.

스테이징에는 이미지가 하나만 업로드된다는 단점이 있습니다(#c25), 프로덕션 환경에서는 좀 다릅니다(1.1), 그러나 우리는 이것이 "물리적으로" 레지스트리의 동일한 이미지라는 것을 알고 있습니다.

진짜 단점은 병합 커밋을 지원하지 않기 때문에 빨리 감아야 한다는 것입니다.

더 나아가 트릭을 수행할 수 있습니다... 간단한 Dockerfile의 예를 살펴보겠습니다.

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

다음 원칙에 따라 파일을 만들어 보겠습니다.

• 사용된 이미지 식별자의 SHA256(ruby:2.3 и nginx:alpine)는 내용의 체크섬입니다.
• 모든 팀 (RUN, CMD 등등.);
• 추가된 파일의 SHA256입니다.

... 그런 파일에서 체크섬(다시 SHA256)을 가져옵니다. 이것 서명 Docker 이미지의 내용을 정의하는 모든 것.

다시 다이어그램으로 돌아가서 커밋 대신 이러한 서명을 사용합니다., 즉. 서명으로 이미지에 태그를 지정하세요.

이제 예를 들어 릴리스의 변경 사항을 마스터로 병합해야 하는 경우 실제 병합 커밋을 수행할 수 있습니다. 식별자는 다르지만 서명은 동일합니다. 동일한 식별자를 사용하여 이미지를 프로덕션에 출시합니다.

단점은 이제 어떤 종류의 커밋이 프로덕션에 푸시되었는지 확인할 수 없다는 것입니다. 체크섬은 한 방향으로만 작동합니다. 이 문제는 메타데이터가 포함된 추가 레이어로 해결됩니다. 자세한 내용은 나중에 설명하겠습니다.

werf에 태그 지정

Werf에서는 더 나아가 하나의 머신에 저장되지 않는 캐시를 사용하여 분산 빌드를 준비하고 있습니다. 그래서 우리는 두 가지 유형의 Docker 이미지를 빌드하고 있습니다. 단계 и 영상.

werf Git 저장소는 빌드의 다양한 단계를 설명하는 빌드별 지침을 저장합니다(설치 전, 설치, 설정 전, 설치). 첫 번째 단계의 체크섬으로 정의된 서명을 사용하여 첫 번째 단계 이미지를 수집합니다. 그런 다음 소스 코드를 추가하고 새 스테이지 이미지에 대해 체크섬을 계산합니다.... 이러한 작업은 모든 스테이지에 대해 반복되어 결과적으로 스테이지 이미지 세트를 얻습니다. 그런 다음 원본에 대한 메타데이터도 포함된 최종 이미지를 만듭니다. 그리고 우리는 이 이미지에 다양한 방식으로 태그를 지정합니다(자세한 내용은 나중에 설명).

그 후에 애플리케이션 코드만 변경된 새 커밋이 나타난다고 가정해 보겠습니다. 무슨 일이 일어날 것? 코드 변경을 위해 패치가 생성되고 새로운 무대 이미지가 준비됩니다. 서명은 이전 스테이지 이미지와 새 패치의 체크섬으로 결정됩니다. 이 이미지로부터 새로운 최종 이미지가 형성됩니다. 다른 단계의 변경에도 비슷한 동작이 발생합니다.

따라서 스테이지 이미지는 분산적으로 저장할 수 있는 캐시이며, 이미 생성된 이미지는 Docker Registry에 업로드됩니다.

레지스트리 청소

태그를 삭제한 후에도 계속 남아 있는 레이어를 삭제하는 것에 대해 말하는 것이 아닙니다. 이는 Docker 레지스트리 자체의 표준 기능입니다. 우리는 많은 Docker 태그가 축적되고 그 중 일부가 더 이상 필요하지 않지만 공간을 차지하거나 비용을 지불하는 상황에 대해 이야기하고 있습니다.

청소 전략은 무엇입니까?

1. 그냥 아무것도 안해도 돼 청소하지 마세요. 때로는 엄청나게 얽힌 태그를 푸는 것보다 추가 공간을 위해 약간의 비용을 지불하는 것이 더 쉽습니다. 그러나 이것은 특정 지점까지만 작동합니다.
2. 전체 재설정. CI 시스템에서 모든 이미지를 삭제하고 현재 이미지만 재구축할 경우 문제가 발생할 수 있습니다. 컨테이너가 프로덕션에서 다시 시작되면 아직 누구도 테스트하지 않은 새 이미지가 로드됩니다. 이것은 불변 인프라에 대한 아이디어를 죽입니다.
3. 청록색. 한 레지스트리가 오버플로되기 시작했습니다. 이미지를 다른 레지스트리에 업로드합니다. 이전 방법과 동일한 문제: 오버플로가 시작된 레지스트리를 어느 시점에서 지울 수 있습니까?
4. 시간대별로. 1개월이 지난 이미지를 모두 삭제하시겠습니까? 하지만 분명 한 달 동안 업데이트가 안 되는 서비스가 있을 텐데…
5. 수동으로 이미 삭제할 수 있는 항목을 결정합니다.

실제로 실행 가능한 두 가지 옵션이 있습니다. 청소하지 않거나 청록색 + 수동 조합을 사용하는 것입니다. 후자의 경우 다음 사항에 대해 이야기하고 있습니다. 레지스트리를 정리해야 할 때라는 것을 이해하면 새 레지스트리를 만들고 예를 들어 한 달 동안 모든 새 이미지를 여기에 추가합니다. 그리고 한 달 후에는 Kubernetes의 어떤 포드가 여전히 이전 레지스트리를 사용하고 있는지 확인하고 이를 새 레지스트리로 전송합니다.

우리는 무엇에 이르렀습니까? 워프? 우리는 다음을 수집합니다:

1. Git 헤드: 모든 태그, 모든 브랜치 - 이미지의 Git에 태그된 모든 것이 필요하다고 가정합니다(그렇지 않은 경우 Git 자체에서 삭제해야 합니다).
2. 현재 Kubernetes로 펌핑되는 모든 포드
3. 이전 ReplicaSet(최근에 릴리스된 것), 그리고 Helm 릴리스를 스캔하고 거기에서 최신 이미지를 선택할 계획도 있습니다.

... 그리고 이 세트에서 삭제하지 않을 이미지 목록인 화이트리스트를 만듭니다. 다른 모든 것을 정리한 후 고아 단계 이미지를 찾아서 삭제합니다.

배포 단계

신뢰할 수 있는 선언성

배포에서 가장 주목하고 싶은 점은 선언적으로 선언된 업데이트된 리소스 구성의 롤아웃입니다. Kubernetes 리소스를 설명하는 원본 YAML 문서는 항상 클러스터에서 실제로 실행되는 결과와 매우 다릅니다. Kubernetes가 구성에 추가하기 때문에:

1. 식별자;
2. 서비스 정보;
3. 많은 기본값;
4. 현재 상태의 섹션;
5. 승인 웹훅의 일부로 변경된 사항
6. 다양한 컨트롤러(및 스케줄러)의 작업 결과입니다.

따라서 새로운 리소스 구성이 나타나면( ), 현재의 "라이브" 구성을 가져와서 덮어쓸 수는 없습니다(살고있다). 이렇게 하려면 비교를 해야 합니다. 마지막으로 적용된 구성(마지막으로 적용된) 그리고 굴러가다 살고있다 패치를 받았습니다.

이 접근 방식을 양방향 병합. 예를 들어 Helm에서 사용됩니다.

도 있습니다 양방향 병합, 이는 다음과 같은 점에서 다릅니다.

• 비교 마지막으로 적용된 и , 삭제된 내용을 살펴봅니다.
• 비교 и 살고있다, 무엇이 추가되거나 변경되었는지 살펴봅니다.
• 합산된 패치가 적용됩니다. 살고있다.

우리는 Helm을 사용하여 1000개 이상의 애플리케이션을 배포하므로 실제로 양방향 병합을 사용하고 있습니다. 그러나 Helm이 정상적으로 작동하는 데 도움이 되는 패치를 통해 해결한 여러 가지 문제가 있습니다.

실제 출시 상태

CI 시스템은 다음 이벤트를 기반으로 Kubernetes에 대한 새로운 구성을 생성한 후 사용을 위해 전송합니다. (적용하다) 클러스터에 - Helm 사용 또는 kubectl apply. 다음으로, 이미 설명한 N 방향 병합이 발생하며, 이에 대해 Kubernetes API는 CI 시스템과 해당 사용자에게 승인적으로 응답합니다.

그러나 큰 문제가 있습니다. 결국 성공적인 적용이 성공적인 출시를 의미하지는 않습니다.. Kubernetes가 어떤 변경 사항을 적용해야 하는지 이해하고 적용하더라도 결과가 어떻게 될지는 아직 알 수 없습니다. 예를 들어 프런트엔드에서 포드를 업데이트하고 다시 시작하면 성공할 수 있지만 백엔드에서는 성공하지 못할 수 있으며 실행 중인 애플리케이션 이미지의 다른 버전을 얻게 됩니다.

모든 작업을 올바르게 수행하려면 이 체계에 추가 링크, 즉 Kubernetes API에서 상태 정보를 수신하고 실제 상태에 대한 추가 분석을 위해 전송하는 특수 추적기가 필요합니다. 우리는 Go에서 오픈 소스 라이브러리를 만들었습니다. 큐브독 (공지사항 참조 여기에), 이 문제를 해결하고 werf에 내장되어 있습니다.

werf 수준에서 이 추적기의 동작은 배포 또는 StatefulSet에 배치된 주석을 사용하여 구성됩니다. 주요 주석 - fail-mode - 다음 의미를 이해합니다.

• IgnoreAndContinueDeployProcess — 우리는 이 구성 요소를 롤아웃하는 데 따른 문제를 무시하고 배포를 계속합니다.
• FailWholeDeployProcessImmediately — 이 구성 요소의 오류로 인해 배포 프로세스가 중지됩니다.
• HopeUntilEndOfDeployProcess — 배포가 끝날 ​​때까지 이 구성 요소가 작동하기를 바랍니다.

예를 들어 리소스와 주석 값의 조합은 다음과 같습니다. fail-mode:

처음 배포할 때 데이터베이스(MongoDB)가 아직 준비되지 않았을 수 있습니다. 배포가 실패합니다. 하지만 시작되는 순간까지 기다릴 수 있으며 배포는 계속 진행됩니다.

werf에는 kubedog에 대한 두 가지 주석이 더 있습니다.

• failures-allowed-per-replica - 각 복제본에 대해 허용된 낙하 횟수
• show-logs-until — werf가 롤아웃된 모든 포드의 로그를 (stdout에서) 표시할 때까지의 순간을 조절합니다. 기본값은 PodIsReady (트래픽이 포드로 들어오기 시작할 때 원하지 않는 메시지를 무시하기 위해) 값도 유효합니다. ControllerIsReady и EndOfDeploy.

배포에서 또 무엇을 원합니까?

이미 설명한 두 가지 사항 외에도 다음을 원합니다.

• 보고 로그 -그리고 필요한 것만 있고 모든 것이 연속되는 것은 아닙니다.
• 길 진행, 작업이 몇 분 동안 "조용히" 중단되면 거기서 무슨 일이 일어나고 있는지 이해하는 것이 중요하기 때문입니다.
• 가지고있다 자동 롤백 문제가 발생한 경우(따라서 배포의 실제 상태를 아는 것이 중요합니다) 롤아웃은 원자적이어야 합니다. 끝까지 진행되거나 모든 것이 이전 상태로 돌아갑니다.

결과

회사로서 우리에게는 다양한 제공 단계(구축, 게시, 배포)에서 설명된 모든 미묘한 차이를 구현하려면 CI 시스템과 유틸리티만으로 충분합니다. 워프.

결론 대신:

Werf의 도움으로 우리는 DevOps 엔지니어를 위한 많은 문제를 해결하는 데 좋은 진전을 이루었으며 더 넓은 커뮤니티에서 적어도 이 유틸리티를 실제로 사용해 볼 수 있다면 기쁠 것입니다. 함께하면 좋은 결과를 얻는 것이 더 쉬울 것입니다.

비디오 및 슬라이드

공연 영상(~47분):

보고서 발표:

PS

블로그의 Kubernetes에 대한 기타 보고서:

• «Kubernetes의 자동 크기 조정 및 리소스 관리» (Dmitry Stolyarov; 27년 2019월 XNUMX일 "Strike" 관련);
• «Kubernetes 확장 및 보완» (Andrey Polovov; 8년 2019월 XNUMX일 Saint HighLoad++);
• «데이터베이스와 Kubernetes» (Dmitry Stolyarov; HighLoad++에서 8년 2018월 XNUMX일);
• «모니터링 및 Kubernetes» (Dmitry Stolyarov; 28년 2018월 XNUMX일 RootConf에서);
• «Kubernetes 및 GitLab을 사용한 CI/CD 모범 사례» (Dmitry Stolyarov; HighLoad++에서 7년 2017월 XNUMX일);
• «소규모 프로젝트에서의 Kubernetes 경험» (Dmitry Stolyarov; 6년 2017월 XNUMX일 RootConf에서).

출처 : habr.com