DomClick의 Kubernetes: 1000개의 마이크로서비스 클러스터를 평화롭게 관리하는 방법

제 이름은 Viktor Yagofarov이고 DomClick에서 Ops(운영) 팀의 기술 개발 관리자로 Kubernetes 플랫폼을 개발하고 있습니다. 저는 Dev <-> Ops 프로세스의 구조, 러시아에서 가장 큰 k8s 클러스터 중 하나를 운영하는 기능, 그리고 우리 팀이 적용하는 DevOps/SRE 방식에 대해 이야기하고 싶습니다.

작전팀

운영팀은 현재 15명으로 구성되어 있습니다. 그 중 XNUMX명은 사무실을 담당하고, XNUMX명은 다른 시간대에서 근무하며 밤에도 근무 가능합니다. 따라서 Ops의 누군가는 항상 모니터 앞에 서서 복잡한 사고에 대응할 준비가 되어 있습니다. 우리는 정신을 보존하고 모든 사람에게 충분한 수면을 취하고 컴퓨터뿐만 아니라 여가 시간을 보낼 수있는 야간 근무가 없습니다.

네트워크 담당자, DBA, ELK 스택 전문가, Kubernetes 관리자/개발자, 모니터링, 가상화, 하드웨어 전문가 등 모든 사람은 서로 다른 역량을 가지고 있습니다. 한 가지가 모두를 하나로 묶습니다. 누구나 어느 정도 우리 중 누구라도 대체할 수 있습니다. 예를 들어 k8s 클러스터에 새 노드 도입, PostgreSQL 업데이트, CI/CD + Ansible 파이프라인 작성, Python/Bash/Go에서 자동화, 하드웨어 연결 등이 있습니다. 데이터 센터. 어떤 영역에서든 강력한 역량이 있다고 해서 활동 방향을 바꾸고 다른 영역에서 개선을 시작하는 것을 방해하지는 않습니다. 예를 들어 저는 PostgreSQL 전문가로 회사에 입사했는데 현재 제가 주로 담당하는 분야는 Kubernetes 클러스터입니다. 팀에서는 어떤 키든 환영하며 레버리지 감각이 매우 발달되어 있습니다.

그건 그렇고, 우리는 사냥 중입니다. 후보자에 대한 요구 사항은 매우 표준적입니다. 개인적으로 사람이 팀에 적응하고 갈등이 없으며 자신의 관점을 방어하는 방법을 알고 발전하기를 원하며 새로운 일을 두려워하지 않고 아이디어를 제공하는 것이 중요합니다. 또한, 스크립팅 언어에 대한 프로그래밍 능력, Linux 및 영어에 대한 기초 지식이 필요합니다. fakap이 발생한 경우 10분이 아닌 10초 안에 문제에 대한 해결책을 Google에 검색할 수 있도록 영어가 필요합니다. 이제 Linux에 대한 깊은 지식을 갖춘 전문가를 찾는 것이 매우 어렵습니다. 우스운 일이지만 후보자 XNUMX명 중 XNUMX명은 "로드 평균이란 무엇입니까?"라는 질문에 대답할 수 없습니다. 무엇으로 만들어졌나요?”, “C 프로그램에서 코어 덤프를 조립하는 방법”이라는 질문은 슈퍼맨이나 공룡의 세계에서 나오는 질문으로 간주됩니다. 일반적으로 사람들은 다른 역량을 고도로 발달시켰지만 우리는 Linux를 가르칠 것이기 때문에 우리는 이것을 참아야 합니다. "현대 클라우드 세계에서 DevOps 엔지니어가 이 모든 것을 알아야 하는 이유"라는 질문에 대한 대답은 기사 범위에서 벗어나야 하지만 세 단어로 말하면 이 모든 것이 필요합니다.

팀 도구

도구 팀은 자동화에서 중요한 역할을 합니다. 그들의 주요 임무는 개발자를 위한 편리한 그래픽 및 CLI 도구를 만드는 것입니다. 예를 들어, 내부 개발 Confer를 사용하면 몇 번의 마우스 클릭만으로 문자 그대로 Kubernetes에 애플리케이션을 롤아웃하고 리소스, 저장소의 키 등을 구성할 수 있습니다. 이전에는 Jenkins + Helm 2가 있었지만 복사-붙여넣기를 제거하고 소프트웨어 수명주기에 통일성을 가져오기 위해 자체 도구를 개발해야 했습니다.

Ops 팀은 개발자를 위한 파이프라인을 작성하지 않지만 작성 시 모든 문제에 대해 조언을 제공할 수 있습니다(일부 사람들은 여전히 ​​Helm 3를 사용하고 있습니다).

개발자

DevOps의 경우 다음과 같습니다.

개발팀은 코드를 작성하고 Confer to dev -> qa/stage -> prod를 통해 이를 출시합니다. 코드가 느려지지 않고 오류가 없는지 확인하는 책임은 Dev 및 Ops 팀에 있습니다. 낮에는 Ops팀 당직자가 먼저 애플리케이션으로 사건에 대응해야 하고, 저녁과 밤에는 당직 관리자(Ops)가 알면 당직 개발자를 깨워야 한다. 문제가 인프라에 있지 않은지 확인하십시오. 모니터링의 모든 지표와 경고는 자동 또는 반자동으로 나타납니다.

Ops의 책임 영역은 애플리케이션이 프로덕션에 출시되는 순간부터 시작되지만 Dev의 책임은 거기서 끝나지 않습니다. 우리는 동일한 작업을 수행하며 동일한 보트에 있습니다.

개발자는 관리 마이크로서비스(예: Go 백엔드 + HTML5)를 작성하는 데 도움이 필요한 경우 관리자에게 조언하고, 관리자는 인프라 문제 또는 k8s와 관련된 문제에 대해 개발자에게 조언합니다.

그건 그렇고, 우리는 모놀리스가 전혀 없고 마이크로서비스만 있습니다. 숫자로 측정하면 지금까지 prod k900s 클러스터에서 그 수는 1000에서 8 사이에서 변동합니다. 배포. Pod 수는 1700~2000개 사이에서 변동합니다. 현재 prod 클러스터에는 약 2000개의 Pod가 있습니다.

불필요한 마이크로서비스를 모니터링하고 반자동으로 잘라내기 때문에 정확한 수치를 말씀드릴 수는 없습니다. K8은 불필요한 엔터티를 추적하는 데 도움이 됩니다. 쓸모없는 연산자, 이는 많은 자원과 비용을 절약합니다.

자원 관리

모니터링

체계적이고 유익한 모니터링은 대규모 클러스터 운영의 초석이 됩니다. 우리는 아직 모든 모니터링 요구 사항을 100% 충족할 수 있는 범용 솔루션을 찾지 못했기 때문에 이 환경에서 정기적으로 다양한 맞춤형 솔루션을 만듭니다.

• 자 비츠. 주로 인프라의 전반적인 상태를 추적하기 위한 오래된 모니터링입니다. 처리, 메모리, 디스크, 네트워크 등의 측면에서 노드가 종료되는 시기를 알려줍니다. 초자연적인 것은 아니지만 별도의 에이전트 DaemonSet도 있습니다. 이를 통해 클러스터의 DNS 상태를 모니터링합니다. 어리석은 coredns 포드를 찾고 외부 호스트의 가용성을 확인합니다. 왜 이것을 귀찮게 하는 것처럼 보이지만 트래픽이 많은 경우 이 구성 요소는 심각한 실패 지점입니다. 이미 나는 설명, 클러스터에서 DNS 성능으로 인해 어려움을 겪은 방법.
• 프로메테우스 오퍼레이터. 다양한 내보내기 세트는 클러스터의 모든 구성 요소에 대한 대규모 개요를 제공합니다. 다음으로, Grafana의 대규모 대시보드에서 이 모든 것을 시각화하고 경고를 위해 Alertmanager를 사용합니다.

우리에게 또 다른 유용한 도구는 목록 수신. 우리는 한 팀이 다른 팀의 Ingress 경로와 겹쳐서 50x 오류가 발생하는 상황을 여러 번 겪은 후에 이 글을 작성했습니다. 이제 프로덕션에 배포하기 전에 개발자는 영향을 받는 사람이 없는지 확인하며, 우리 팀에게 이는 Ingress 문제의 초기 진단을 위한 좋은 도구입니다. 처음에는 관리자를 위해 작성되었고 다소 "서투른" 것처럼 보였지만 개발팀이 도구에 푹 빠진 후에는 많이 바뀌었고 "관리자가 관리자를 위해 웹 페이스를 만든" 것처럼 보이지 않기 시작했습니다. ” 곧 우리는 이 도구를 폐기할 것이며 그러한 상황은 파이프라인이 출시되기 전에도 검증될 것입니다.

큐브의 팀 리소스

예제에 들어가기 전에 리소스를 할당하는 방법을 설명하는 것이 좋습니다. 마이크로서비스.

어떤 팀이 얼마나 많은 양을 사용하는지 이해하려면 ресурсы (프로세서, 메모리, 로컬 SSD), 각 명령을 자체적으로 할당합니다. 네임 스페이스 이전에 팀의 요구 사항을 논의한 후 "큐브"에서 프로세서, 메모리 및 디스크 측면에서 최대 성능을 제한합니다. 따라서 일반적으로 하나의 명령은 배포를 위해 전체 클러스터를 차단하지 않고 수천 개의 코어와 테라바이트의 메모리를 할당합니다. 네임스페이스에 대한 액세스는 AD(RBAC 사용)를 통해 부여됩니다. 네임스페이스와 해당 제한은 풀 요청을 통해 GIT 저장소에 추가된 다음 모든 것이 Ansible 파이프라인을 통해 자동으로 롤아웃됩니다.

팀에 리소스를 할당하는 예:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

요청 및 한도

큐브형" 의뢰 보장된 예약 리소스 수입니다. 포드 (하나 이상의 Docker 컨테이너)를 클러스터에 포함합니다. 한도는 보장되지 않는 최대값입니다. 일부 팀이 모든 애플리케이션에 대해 너무 많은 요청을 설정하고 해당 네임스페이스 아래의 모든 요청이 이미 "사용"되었기 때문에 애플리케이션을 "큐브"에 배포할 수 없는 방법을 그래프에서 자주 볼 수 있습니다.

이러한 상황을 해결하는 올바른 방법은 실제 리소스 소비량을 살펴보고 이를 요청한 양(요청)과 비교하는 것입니다.

위의 스크린샷에서 "요청된" CPU가 실제 스레드 수와 일치하고 제한이 실제 CPU 스레드 수를 초과할 수 있음을 알 수 있습니다 =)

이제 일부 네임스페이스를 자세히 살펴보고(저는 "큐브" 자체의 구성 요소에 대한 시스템 네임스페이스인 kube-system 네임스페이스를 선택했습니다) 실제로 사용된 프로세서 시간과 메모리 대 요청된 시간의 비율을 살펴보겠습니다.

실제로 사용되는 것보다 훨씬 더 많은 메모리와 CPU가 시스템 서비스용으로 예약되어 있다는 것은 분명합니다. kube-system의 경우 이는 정당합니다. nginx 수신 컨트롤러 또는 nodelocaldns가 최고조에 달했을 때 CPU에 도달하고 많은 RAM을 소비했기 때문에 여기서는 그러한 예약이 정당합니다. 또한 지난 3시간 동안의 차트에 의존할 수 없습니다. 장기간에 걸친 기록 측정항목을 보는 것이 바람직합니다.

"권장사항" 시스템이 개발되었습니다. 예를 들어, 여기서는 "제한"(허용되는 상위 막대)을 높여 "제한"이 발생하지 않도록 하는 것이 더 나은 리소스를 확인할 수 있습니다. 즉, 리소스가 할당된 시간 분할에서 CPU 또는 메모리를 이미 사용한 순간 및 "고정 해제"될 때까지 기다리고 있습니다.

식욕을 억제해야 하는 꼬투리는 다음과 같습니다.

약 조절 + 리소스 모니터링으로 글을 XNUMX개 이상 작성할 수 있으니 궁금한 점은 댓글로 질문해주세요. 간단히 말해서, 이러한 측정 항목을 자동화하는 작업은 매우 어렵고 많은 시간이 필요하며 "창" 기능 및 "CTE" Prometheus/VictoriaMetrics와의 균형 작업이 필요하다고 말할 수 있습니다. PromQL에서는 이와 같은 것이 없으며 무서운 쿼리를 여러 텍스트 화면으로 나누어 최적화해야 합니다.

결과적으로 개발자는 Cube에서 자신의 네임스페이스를 모니터링할 수 있는 도구를 갖게 되며, 어느 응용 프로그램이 리소스를 "절단"할 수 있는지, 밤새도록 전체 CPU를 제공할 수 있는 서버를 언제, 어디서 스스로 선택할 수 있습니다.

방법론

회사에서는 지금처럼 유행의, 우리는 DevOps를 준수합니다. SRE- 실무자 회사에 1000개의 마이크로서비스, 전체 인프라에 대한 약 350명의 개발자 및 15명의 관리자가 있는 경우 "유행"해야 합니다. 이러한 모든 "기본" 뒤에는 모든 것과 모든 사람을 자동화해야 하는 긴급한 필요성이 있으며 관리자는 병목 현상이 있어서는 안 됩니다. 프로세스에서.

Ops로서 우리는 개발자에게 서비스 응답률 및 오류와 관련된 다양한 지표와 대시보드를 제공합니다.

우리는 다음과 같은 방법론을 사용합니다. RED, 사용 и 골든 시그널그것들을 함께 결합함으로써. 우리는 현재 어떤 서비스가 저하되고 있는지 한눈에 알 수 있도록 대시보드 수를 최소화하려고 노력합니다(예: 초당 응답 코드, 99번째 백분위수에 따른 응답 시간). 일반 대시보드에 새로운 지표가 필요하게 되면 즉시 이를 그려서 추가합니다.

한 달 동안 그래프를 그리지 않았습니다. 이는 아마도 좋은 신호일 것입니다. 이는 대부분의 "원하는 것"이 ​​이미 실현되었음을 의미합니다. 주중에는 적어도 하루에 한 번씩 새로운 그래프를 그리는 일이 일어났습니다.

이제 개발자가 관리자에게 "어떤 종류의 측정 항목을 볼 수 있는지"에 대한 질문을 하는 경우가 거의 없기 때문에 결과 결과는 가치가 있습니다.

구현 서비스 메시 곧 출시될 예정이며 모든 사람의 삶이 훨씬 더 쉬워질 것입니다. Tools의 동료들은 이미 추상적인 "건강한 사람의 Istio" 구현에 가까워졌습니다. 각 HTTP(s) 요청의 수명 주기는 모니터링에서 볼 수 있으며 서비스 간(뿐만 아니라) 상호 작용 중에 "모든 단계에서 모든 것이 중단되었는지"를 항상 이해할 수 있습니다. DomClick 허브의 뉴스를 구독하세요. =)

Kubernetes 인프라 지원

역사적으로 우리는 패치 버전을 사용합니다 큐브스프레이 — Kubernetes 배포, 확장, 업데이트를 위한 Ansible 역할입니다. 어떤 시점에서는 kubeadm이 아닌 설치에 대한 지원이 메인 브랜치에서 중단되었고 kubeadm으로 전환하는 프로세스가 제안되지 않았습니다. 결과적으로 Southbridge 회사는 자체 포크를 만들었습니다(kubeadm 지원 및 중요한 문제에 대한 빠른 수정 포함).

모든 k8s 클러스터를 업데이트하는 프로세스는 다음과 같습니다.

• 우리는 큐브스프레이 Southbridge에서 Merjim이라는 스레드를 확인해보세요.
• 다음 업데이트를 출시하고 있습니다. 스트레스- "큐브".
• 한 번에 한 노드씩 업데이트를 롤아웃합니다(Ansible에서는 "직렬: 1"임). 데브- "큐브".
• 업데이트한다 자극하다 토요일 저녁에는 한 번에 한 노드씩.

추후에 교체할 ​​계획이 있습니다 큐브스프레이 더 빨리 뭔가를 위해 가십시오 kubeadm.

전체적으로 Stress, Dev 및 Prod의 세 가지 "큐브"가 있습니다. 우리는 또 다른 제품을 출시할 계획입니다(핫 대기) 두 번째 데이터 센터의 Prod-“Cube”. 스트레스 и 데브 "가상 머신"(Stress용 oVirt 및 Dev용 VMWare 클라우드)에 살고 있습니다. 자극하다- "큐브"는 "베어 메탈"에 있습니다. 이는 CPU 스레드 32개, 메모리 64~128GB, SSD RAID 300 10GB를 갖춘 동일한 노드입니다. 총 50개가 있습니다. XNUMX개의 "씬" 노드가 "마스터" 전용입니다. 자극하다- "쿠바": 16GB 메모리, 12개 CPU 스레드.

판매를 위해서는 "베어메탈"을 사용하고 다음과 같은 불필요한 레이어를 피하는 것을 선호합니다. OpenStack: "시끄러운 이웃"과 CPU가 필요하지 않습니다. 시간을 훔치다. 그리고 사내 OpenStack의 경우 관리 복잡성이 약 두 배로 늘어납니다.

CI/CD "Cubic" 및 기타 인프라 구성 요소의 경우 별도의 GIT 서버인 Helm 3을 사용합니다(Helm 2에서 전환하는 것은 다소 고통스러웠지만 옵션에 매우 만족합니다) 원자의), 젠킨스, 앤서블, 도커. 우리는 하나의 저장소에서 기능 분기와 다양한 환경으로의 배포를 좋아합니다.

결론

이는 일반적으로 운영 엔지니어의 관점에서 DomClick의 DevOps 프로세스가 어떻게 보이는지 보여줍니다. 기사는 내가 예상했던 것보다 덜 기술적인 것으로 판명되었습니다. 따라서 Habré의 DomClick 뉴스를 따르세요. Kubernetes 등에 대한 더 많은 "하드코어" 기사가 있을 것입니다.

출처 : habr.com