Kubernetes에서 애플리케이션 개발을 위한 요구 사항

오늘 저는 애플리케이션을 작성하는 방법과 Kubernetes에서 애플리케이션이 제대로 작동하기 위한 요구 사항에 대해 이야기할 계획입니다. 애플리케이션에 문제가 생기지 않도록 주변에 "충돌"을 고안하고 구축할 필요가 없으며 모든 것이 Kubernetes 자체가 의도한 대로 작동합니다.

이번 강의는 "Kubernetes의 Slurm Night School" 저녁학교의 공개 이론강의를 보실 수 있습니다 YouTube에서 재생목록으로 그룹화됨. 영상보다 텍스트를 선호하시는 분들을 위해 이 글을 준비했습니다.

제 이름은 Pavel Selivanov입니다. 현재 저는 Mail.ru Cloud Solutions의 선도적인 DevOps 엔지니어로 클라우드를 만들고, Kubernetes 관리 등을 만들고 있습니다. 이제 내 작업에는 개발 지원, 이러한 클라우드 출시, 우리가 작성한 애플리케이션 출시, 사용자에게 제공하는 도구 직접 개발이 포함됩니다.

저는 DevOps를 해왔습니다. 아마도 지난 XNUMX년 정도였던 것 같습니다. 하지만 원칙적으로 저는 DevOps가 하는 일을 지금까지 약 XNUMX년 동안 해왔습니다. 그 전에는 주로 관리 업무에 참여했습니다. 저는 오래 전부터 Kubernetes를 사용하기 시작했습니다. 아마도 작업을 시작한 지 약 XNUMX년이 지났을 것입니다.

일반적으로 저는 Kubernetes 버전이 1.3, 아마도 1.2일 때 시작했습니다. 아직 초기 단계였을 때죠. 이제 더 이상 초기 단계가 아니며, Kubernetes를 사용하고 싶어하는 엔지니어에 대한 시장 수요가 크다는 것은 분명합니다. 그리고 기업에서는 그런 인재에 대한 수요가 매우 높습니다. 그래서 실제로 이 강의가 나온 것이다.

내가 이야기할 계획에 따라 말하면 다음과 같습니다. 괄호 안에는 (TL;DR) – “너무 길다; 읽지 마세요." 오늘 내 프레젠테이션은 끝없는 목록으로 구성될 것입니다.

사실 나 자신도 그런 프레젠테이션이 만들어지는 것을 좋아하지 않지만, 이것은 내가 이 프레젠테이션을 준비할 때 이 정보를 다르게 구성하는 방법을 실제로 이해하지 못했던 주제입니다.

대체로 이 정보는 DevOps 섹션의 Wiki에서 가져온 "ctrl+c, ctrl+v"이기 때문에 개발자를 위한 요구 사항을 작성했습니다. 쿠버네티스, 이렇게 돼야지."

그래서 프레젠테이션의 목록이 이렇게나 방대해졌습니다. 죄송합니다. 가능하다면 지루하지 않게 최대한 많은 이야기를 하도록 노력하겠습니다.

지금 우리가 살펴볼 내용은 다음과 같습니다.

• 이것은 첫째로 로그(애플리케이션 로그?), Kubernetes에서 로그로 무엇을 해야 하는지, 어떻게 해야 하는지, 무엇이 되어야 하는지입니다.
• Kubernetes의 구성으로 무엇을 해야 하는지, Kubernetes용 애플리케이션을 구성하는 가장 좋은 방법과 최악의 방법은 무엇입니까?
• 일반적으로 접근성 검사가 무엇인지, 어떤 모습이어야 하는지에 대해 이야기해 보겠습니다.
• 우아한 종료가 무엇인지 이야기해 보겠습니다.
• 자원에 대해 다시 이야기해 보겠습니다.
• 데이터 저장 주제를 다시 한 번 다루겠습니다.
• 마지막에는 이 신비로운 클라우드 네이티브 애플리케이션이라는 용어가 무엇인지 말씀드리겠습니다. 클라우드 네이티브성(이 용어의 형용사)

로그

로그부터 시작하는 것이 좋습니다. 이러한 로그를 Kubernetes에 넣어야 하는 위치부터 시작하세요. 이제 Kubernetes에서 애플리케이션을 시작했습니다. 고전에 따르면 이전 애플리케이션은 항상 파일 어딘가에 로그를 기록했습니다. 잘못된 응용 프로그램은 해당 응용 프로그램을 시작한 개발자의 홈 디렉터리에 있는 파일에 로그를 기록했습니다. 좋은 애플리케이션은 다음 위치의 파일에 로그를 기록했습니다. /var/log.

따라서 훌륭한 관리자는 인프라에 이러한 로그가 순환될 수 있는 몇 가지 항목을 구성했습니다. 동일한 rsyslog는 이러한 로그를 살펴보고 문제가 발생하면 많은 로그가 있고 백업 복사본을 생성하고 거기에 로그를 저장합니다. , 일주일, XNUMX개월 이상 오래된 파일을 삭제합니다. 이론적으로는 단순히 애플리케이션이 로그를 작성한다고 해서 프로덕션 서버(전투 서버?)의 공간이 부족해지지 않도록 대비해야 합니다. 따라서 로그 때문에 전체 생산이 중단되지 않았습니다.

Kubernetes의 세계로 이동하여 그곳에서 동일한 작업을 실행할 때 가장 먼저 주목해야 할 것은 사람들이 파일에 로그를 작성한 대로 계속해서 작성한다는 사실입니다.

Kubernetes에 대해 이야기하면 Docker 컨테이너 어딘가에 로그를 작성하는 올바른 장소는 단순히 애플리케이션에서 소위 Stdout/Stderr, 즉 운영 체제의 표준 출력 스트림으로 로그를 작성하는 것입니다. 표준 오류 출력. 이는 원칙적으로 Docker, 특히 Kubernetis에 로그를 넣는 가장 정확하고 간단하며 가장 논리적인 방법입니다. 애플리케이션이 Stdout/Stderr에 로그를 기록하는 경우 이러한 로그로 무엇을 할지 결정하는 것은 Docker와 Kubernetes 추가 기능에 달려 있기 때문입니다. Docker는 기본적으로 JSON 형식으로 특수 파일을 빌드합니다.

여기서 질문이 생깁니다. 다음에 이 로그로 무엇을 하시겠습니까? 가장 쉬운 방법은 분명합니다. 우리는 할 수 있는 능력이 있습니다. kubectl logs 이러한 "포드"의 로그를 살펴보세요. 그러나 아마도 이것은 그다지 좋은 옵션은 아닙니다. 로그를 사용하여 다른 작업을 수행해야 합니다.

지금은 로그라는 주제를 다루었으므로 동시에 로그가 어떤 모습이어야 하는지에 대해 이야기해 보겠습니다. 즉, 쿠버네티스에 직접적으로 적용되는 것은 아니지만, 로그를 어떻게 할지 고민을 시작할 때 이것 역시 생각해 보는 것이 좋을 것 같습니다.

우리는 도커가 파일에 넣은 로그를 가져와 어딘가로 보낼 수 있는 우호적인 방식의 도구가 필요합니다. 전반적으로 우리는 일반적으로 Docker가 수집하는 로그의 위치를 ​​알려주는 로그 수집기인 DaemonSet의 형태로 Kubernetes 내에서 일종의 에이전트를 시작합니다. 그리고 이 수집 에이전트는 단순히 그것들을 가져오고, 아마도 어떻게든 길을 따라 그것들을 구문 분석하고, 아마도 추가적인 메타 정보로 그것들을 풍부하게 하고 궁극적으로 저장을 위해 어딘가에 보낼 것입니다. 이미 변형이 가능합니다. 가장 일반적인 것은 로그를 저장하고 거기에서 편리하게 검색할 수 있는 Elasticsearch일 것입니다. 그런 다음 요청을 사용하여 Kibana 등을 사용하여 이를 기반으로 그래프를 작성하고 이를 기반으로 경고를 작성하는 등의 작업을 수행합니다.

다시 반복하고 싶은 가장 중요한 아이디어는 Docker 내부, 특히 Kubernetes 내부에서 로그를 파일에 저장하는 것은 매우 나쁜 생각이라는 것입니다.

첫째, 컨테이너 내부의 로그를 파일로 가져오는 것이 어렵기 때문입니다. 먼저 컨테이너로 이동하여 그곳에서 실행한 다음 로그를 살펴봐야 합니다. 다음 요점은 파일에 로그가 있는 경우 컨테이너는 일반적으로 최소한의 환경을 가지며 일반적으로 로그 작업에 필요한 유틸리티가 없다는 것입니다. 묻어두고, 살펴보고, 텍스트 편집기에서 열어보세요. 다음 순간은 컨테이너 내부의 파일에 로그가 있을 때입니다. 이 컨테이너가 삭제되면 로그도 함께 삭제됩니다. 따라서 컨테이너를 다시 시작하면 더 이상 로그가 없다는 의미입니다. 다시 말하지만, 나쁜 선택입니다.

마지막 요점은 컨테이너 내부에 일반적으로 애플리케이션이 있고 그게 전부라는 것입니다. 일반적으로 애플리케이션이 실행되는 유일한 프로세스입니다. 로그와 함께 파일을 회전시키는 프로세스에 대해서는 전혀 이야기가 없습니다. 로그가 파일에 기록되기 시작하자마자 이는 죄송하지만 프로덕션 서버를 잃기 시작한다는 것을 의미합니다. 첫째, 찾기가 어렵고, 추적하는 사람도 없고, 제어하는 ​​사람도 없기 때문입니다. 따라서 서버 공간이 다 떨어질 때까지 파일은 끝없이 커집니다. 따라서 Docker, 특히 Kubernetes에서 파일에 로그인하는 것은 좋지 않은 생각이라는 점을 다시 한 번 말씀드립니다.

다음 요점은 이것에 대해 다시 이야기하고 싶습니다. 로그 주제를 다루고 있기 때문에 로그 작업을 편리하게 만들기 위해 로그가 어떻게 보이는지에 대해 이야기하는 것이 좋을 것입니다. 앞서 말했듯이 주제는 Kubernetes와 직접적인 관련이 없지만 DevOps라는 주제와 매우 잘 관련되어 있습니다. Dev와 Ops라는 서로 다른 두 부서 간의 개발 문화와 우정을 주제로 모든 사람이 편안하게 지낼 수 있도록 합니다.

이는 이상적으로는 오늘날 로그가 JSON 형식으로 작성되어야 함을 의미합니다. 일종의 인쇄물 등을 삽입하여 이해할 수 없는 형식으로 로그를 작성하는 이해할 수 없는 애플리케이션이 있는 경우, 이제 일반적인 로깅을 구현할 수 있는 일종의 프레임워크, 래퍼를 Google에 검색할 때입니다. JSON은 간단한 형식이므로 구문 분석이 간단하므로 JSON에서 로깅 매개변수를 활성화합니다.

JSON이 일부 기준에 따라 작동하지 않는 경우, 아무도 그 사실을 알지 못하므로 최소한 구문 분석할 수 있는 형식으로 로그를 작성하십시오. 오히려 여기서는 예를 들어 여러 컨테이너를 실행하거나 nginx를 사용하여 프로세스를 실행하고 각각 고유한 로깅 설정이 있는 경우 다음을 수행하는 것이 매우 불편할 것 같다는 사실을 생각해 볼 가치가 있습니다. 그것들을 구문 분석하십시오. 새로운 nginx 인스턴스마다 로그를 다르게 작성하기 때문에 자체 파서를 작성해야 하기 때문입니다. 다시 말하지만, 이러한 모든 nginx 인스턴스가 동일한 로깅 구성을 가지며 모든 로그가 완전히 균일하게 작성되었는지 확인하는 것이 아마도 가치가 있을 것입니다. 모든 응용 프로그램에도 동일하게 적용됩니다.

결국 나는 이상적으로는 여러 줄 형식의 로그를 피해야 한다는 불에 연료를 추가하고 싶습니다. 로그 수집기로 작업해 본 적이 있다면 그들이 약속하는 것, 여러 줄의 로그로 작업할 수 있다는 것, 수집 방법 등을 알았을 것입니다. 사실, 제 생각에는 오늘날 단 한 명의 수집가도 여러 줄의 로그를 오류 없이 정상적으로 완전하게 수집할 수 없습니다. 인간적인 방식으로 편리하고 오류가 없도록 합니다.

그러나 스택 추적은 항상 여러 줄의 로그이며 이를 방지하는 방법입니다. 여기서 문제는 로그는 이벤트 기록이고 stactrace는 실제로 로그가 아니라는 것입니다. 로그를 수집하여 Elasticsearch 어딘가에 저장한 다음 그래프를 그리고 사이트의 사용자 활동에 대한 일부 보고서를 작성한 다음 스택 추적을 받으면 애플리케이션에서 처리되지 않은 상황인 예상치 못한 상황이 발생했음을 의미합니다. 그리고 이를 추적할 수 있는 시스템 어딘가에 스택 추적을 자동으로 업로드하는 것이 합리적입니다.

이것은 스택 추적 작업을 위해 특별히 제작된 소프트웨어(동일한 Sentry)입니다. 즉시 자동화된 작업을 생성하고, 이를 다른 사람에게 할당하고, stacttrace가 발생할 때 경고하고, 이러한 stacttrace를 한 가지 유형으로 그룹화하는 등의 작업을 수행할 수 있습니다. 원칙적으로 로그에 대해 이야기할 때 스택트레이스에 대해 이야기하는 것은 별 의미가 없습니다. 왜냐하면 결국 로그는 목적이 다르고 다른 것이기 때문입니다.

구성

다음으로 Kubernetes의 구성, 즉 이를 사용하여 수행할 작업과 Kubernetes 내부 애플리케이션을 구성하는 방법에 대해 이야기합니다. 일반적으로 저는 Docker가 컨테이너에 관한 것이 아니라고 말합니다. Docker를 많이 사용하지 않은 사람이라도 Docker가 컨테이너에 관한 것이라는 것은 누구나 알고 있습니다. 반복합니다. Docker는 컨테이너에 관한 것이 아닙니다.

내 생각에 Docker는 표준에 관한 것입니다. 그리고 실제로 모든 것에 대한 표준이 있습니다. 즉, 애플리케이션 구축 표준, 애플리케이션 설치 표준이 있습니다.

그리고 이것은 이전에 사용했지만 컨테이너의 출현으로 특히 인기를 얻었습니다. 이것을 ENV(환경) 변수, 즉 운영 체제에 있는 환경 변수라고 합니다. 이는 일반적으로 애플리케이션을 구성하는 이상적인 방법입니다. 왜냐하면 JAVA, Python, Go, Perl, God forbid로 작성된 애플리케이션이 있고 데이터베이스 호스트, 데이터베이스 사용자, 데이터베이스 비밀번호 변수를 모두 읽을 수 있다면 이상적이기 때문입니다. 동일한 방식으로 데이터베이스 계획에 구성된 XNUMX가지 언어의 애플리케이션이 있습니다. 더 이상 다른 구성이 없습니다.

ENV 변수를 사용하여 모든 것을 구성할 수 있습니다. Kubernetes에 관해 이야기할 때 배포 내에서 바로 ENV 변수를 선언할 수 있는 좋은 방법이 있습니다. 따라서 비밀 데이터에 관해 이야기하는 경우 ENV 변수(데이터베이스의 비밀번호 등)의 비밀 데이터를 즉시 비밀로 푸시하고, 비밀 클러스터를 생성하고, 배포의 ENV 설명에 직접 선언하지 않음을 표시할 수 있습니다. 이 변수의 값과 이 데이터베이스 비밀번호 변수의 값은 비밀에서 읽혀집니다. 이는 표준 Kubernetes 동작입니다. 이는 애플리케이션을 구성하는 데 가장 이상적인 옵션입니다. 코드 수준에서도 이는 개발자에게 적용됩니다. DevOps라면 다음과 같이 질문할 수 있습니다. “여러분, 애플리케이션에 환경 변수를 읽도록 가르쳐 주세요. 그리고 우리 모두는 행복해질 것입니다.”

회사의 모든 사람이 동일한 이름의 환경 변수를 읽는다면 좋습니다. 일부는 postgres 데이터베이스를 기다리고, 다른 일부는 데이터베이스 이름을 기다리고, 다른 일부는 다른 것을 기다리고, 다른 일부는 일종의 DBN을 기다리는 일이 발생하지 않도록 하여 그에 따라 균일성이 있습니다.

배포를 열었을 정도로 환경 변수가 너무 많고 환경 변수 줄이 XNUMX줄에 달할 때 문제가 발생합니다. 이 경우 환경 변수가 너무 커져서 더 이상 스스로를 고문할 필요가 없습니다. 이 경우 구성 사용을 시작하는 것이 좋습니다. 즉, 구성을 사용하도록 애플리케이션을 교육합니다.

유일한 질문은 구성이 당신이 생각하는 것과 다르다는 것입니다. Config.pi는 사용하기 편리한 구성이 아닙니다. 또는 자신만의 형식으로 구성하거나 다른 방식으로 재능을 부여할 수도 있습니다. 이것은 또한 제가 의미하는 구성이 아닙니다.

내가 말하는 것은 허용 가능한 형식의 구성입니다. 즉, 가장 널리 사용되는 표준은 .yaml 표준입니다. 읽는 방법이 명확하고, 사람이 읽을 수 있으며, 애플리케이션에서 읽는 방법도 명확합니다.

따라서 YAML 외에도 JSON 등을 사용할 수도 있습니다. 구문 분석은 거기에서 애플리케이션 구성을 읽는 측면에서 YAML만큼 편리합니다. 사람들이 읽는 것이 눈에 띄게 더 불편합니다. a la ini 형식을 사용해 볼 수 있습니다. 인간의 관점에서는 읽기가 매우 편리하지만 자동으로 처리하는 것은 불편할 수 있습니다. 즉, 자신만의 구성을 생성하려는 경우 ini 형식이 이미 생성하기 불편할 수 있다는 점입니다.

그러나 어쨌든 어떤 형식을 선택하든 요점은 Kubernetes의 관점에서 볼 때 매우 편리하다는 것입니다. 전체 구성을 Kubernetes 내부의 ConfigMap에 넣을 수 있습니다. 그런 다음 이 구성 맵을 가져와 포드 내부의 특정 디렉터리에 마운트하도록 요청하세요. 그러면 애플리케이션이 이 구성 맵에서 마치 파일인 것처럼 구성을 읽습니다. 실제로 이는 애플리케이션에 구성 옵션이 많을 때 수행하는 것이 좋습니다. 아니면 일종의 복잡한 구조일 뿐이고 중첩이 있습니다.

configmap이 있는 경우 예를 들어 configmap이 마운트된 파일의 변경 사항을 자동으로 추적하고 구성이 변경되면 자동으로 애플리케이션을 다시 로드하도록 애플리케이션을 교육할 수 있습니다. 이는 일반적으로 이상적인 옵션입니다.

다시 한번 말하지만, 나는 이것에 대해 이미 이야기했습니다. 비밀 정보는 configmap에 없고, 비밀 정보는 변수에 없고, 비밀 정보는 비밀에 없습니다. 거기에서 이 비밀 정보를 외교와 연결하세요. 일반적으로 우리는 Kubernetes 개체, 배포, 구성 맵, 서비스에 대한 모든 설명을 git에 저장합니다. 따라서 회사 내부에 보유하고 있는 git이라 하더라도 데이터베이스에 비밀번호를 git에 입력하는 것은 좋지 않은 생각입니다. 최소한 git은 모든 것을 기억하고 단순히 비밀번호를 제거하는 것이 그렇게 쉽지 않기 때문입니다.

건강 체크

다음 포인트는 Health check라는 것입니다. 일반적으로 상태 확인은 단순히 애플리케이션이 작동하는지 확인하는 것입니다. 동시에, 우리는 특정 웹 애플리케이션에 대해 가장 자주 이야기하고 있으며, 이에 따라 상태 확인의 관점에서(여기서 더 이상 번역하지 않는 것이 더 좋음) 이것은 다음과 같이 처리되는 특수 URL이 될 것입니다. 표준에 따르면 일반적으로 그렇습니다. /health.

따라서 이 URL에 액세스할 때 우리 애플리케이션은 "예, 알겠습니다. 모든 것이 괜찮습니다. 200" 또는 "아니요, 모든 것이 괜찮지 않습니다. 약 500"이라고 말합니다. 따라서 우리 애플리케이션이 웹 애플리케이션이 아닌 http가 아닌 경우 이제 일종의 데몬에 대해 이야기하고 있으며 상태 확인 방법을 알아낼 수 있습니다. 즉, 애플리케이션이 http가 아닌 경우에는 상태 확인 없이 모든 것이 작동하며 어떤 방식으로도 이를 수행할 수 없습니다. 파일의 일부 정보를 주기적으로 업데이트할 수 있으며, 다음과 같이 데몬에 대한 특별한 명령을 내릴 수 있습니다. daemon status, 이는 "예, 모든 것이 정상입니다. 데몬이 작동하고 있으며 살아 있습니다."라고 말합니다.

그것은 무엇을 위한 것입니까? 가장 먼저이자 가장 분명한 것은 애플리케이션이 작동하는지 이해하기 위해 상태 점검이 필요한 이유일 것입니다. 내 말은, 그것은 단지 어리석은 일이지만, 지금 일어나면 작동하는 것처럼 보이므로 작동하고 있다고 확신할 수 있습니다. 그리고 애플리케이션이 실행되고, 컨테이너가 실행되고, 인스턴스가 작동하고, 모든 것이 정상이라는 것이 밝혀졌습니다. 그런 다음 사용자는 이미 기술 지원의 모든 전화 번호를 차단하고 "당신은 무엇입니까 ..., 당신은 무엇입니까?"라고 말합니다. 잠이 들었는데 아무 일도 일어나지 않네요.”

상태 점검은 사용자의 관점에서 그것이 작동하는지 확인하는 방법입니다. 방법 중 하나입니다. 이렇게 표현해보자. Kubernetes의 관점에서 볼 때 이는 애플리케이션이 시작되는 시점을 이해하는 방법이기도 합니다. 컨테이너가 시작되고 생성되고 시작된 시점과 애플리케이션이 이 컨테이너에서 직접 실행된 시점에 차이가 있음을 이해하기 때문입니다. 왜냐하면 일반적인 Java 애플리케이션을 가져와서 도크에서 실행하려고 하면 XNUMX초, 심지어 XNUMX분, 심지어 XNUMX초 동안이라도 정상적으로 시작될 수 있기 때문입니다. 이 경우 최소한 해당 포트를 노크할 수는 있지만 응답하지 않습니다. 즉, 아직 트래픽을 수신할 준비가 되지 않았습니다.

다시 말하지만, 상태 확인과 여기에서 살펴보는 사실을 통해 우리는 Kubernetes에서 컨테이너가 애플리케이션에서 상승했을 뿐만 아니라 애플리케이션 자체가 시작되었으며 이미 요청에 응답하고 있음을 이해할 수 있습니다. 상태 확인은 트래픽을 그곳으로 보낼 수 있음을 의미합니다.

지금 제가 말하는 것은 Kubernetes 내의 준비/활성 테스트라고 하며, 따라서 우리의 준비 테스트는 밸런싱에서 애플리케이션의 가용성을 담당합니다. 즉, 애플리케이션에서 준비 테스트가 수행되면 모든 것이 정상이며 클라이언트 트래픽이 애플리케이션으로 이동합니다. 준비 테스트가 수행되지 않으면 애플리케이션이 단순히 참여하지 않고 이 특정 인스턴스가 밸런싱에 참여하지 않으며 밸런싱에서 제거되고 클라이언트 트래픽이 흐르지 않습니다. 따라서 애플리케이션이 중단되면 다시 시작할 수 있도록 Kubernetes 내의 활성 테스트가 필요합니다. Kubernetes에 선언된 애플리케이션에 대해 활성 테스트가 작동하지 않으면 해당 애플리케이션은 밸런싱에서 제거될 뿐만 아니라 다시 시작됩니다.

그리고 여기에 제가 언급하고 싶은 중요한 점이 있습니다. 실용적인 관점에서 보면 준비성 테스트는 일반적으로 활성성 테스트보다 더 자주 사용되며 더 자주 필요합니다. 즉, 단순히 준비 상태와 활성 상태 테스트를 모두 무심코 선언하는 것은 Kubernetes가 그렇게 할 수 있고 가능한 모든 것을 활용하는 것은 별로 좋은 생각이 아닙니다. 이유를 설명하겠습니다. 테스트의 두 번째 요점은 상태 확인에서 기본 서비스를 확인하는 것이 좋은 생각이기 때문입니다. 이는 일부 정보를 제공하는 웹 애플리케이션이 있는 경우 자연스럽게 어딘가에서 가져와야 함을 의미합니다. 예를 들어 데이터베이스에서. 음, 이 REST API에 들어오는 정보를 동일한 데이터베이스에 저장합니다. 따라서 귀하의 healthcheck가 slashhealth에 연락한 것처럼 간단하게 응답하면 애플리케이션은 "200, 알겠습니다, 모든 것이 괜찮습니다"라고 말하고 동시에 애플리케이션의 데이터베이스에 액세스할 수 없으며 healthcheck 애플리케이션은 "200, 알겠습니다, 모든 것이 괜찮습니다"라고 말합니다. ” - 이것은 나쁜 건강 검진입니다. 이것은 작동 방식이 아닙니다.

즉, 요청이 오면 애플리케이션입니다. /health, 단순히 "200, ok"라고 응답하는 것이 아니라 먼저 데이터베이스로 가서 연결을 시도하고 거기에서 하나를 선택하는 등 매우 기본적인 작업을 수행하고 데이터베이스에 연결이 있는지 확인합니다. 데이터베이스를 사용하여 데이터베이스를 쿼리할 수 있습니다. 이 모든 것이 성공했다면 대답은 "200, ok"입니다. 성공하지 못하면 오류가 발생하여 데이터베이스를 사용할 수 없다는 메시지가 나타납니다.

따라서 이와 관련하여 다시 준비/활성 테스트로 돌아가겠습니다. 준비 테스트가 가장 필요한데 활성 테스트가 문제가 되는 이유입니다. 방금 말한 대로 상태 확인을 정확하게 설명하면 인스턴스 부분에서는 사용할 수 없는 것으로 판명되기 때문입니다.в или со всех instance예를 들어 데이터베이스에서. 준비 테스트를 선언했을 때 상태 확인이 실패하기 시작했고 그에 따라 데이터베이스에 액세스할 수 없는 모든 애플리케이션은 단순히 밸런싱에서 꺼지고 실제로는 무시된 상태에서 "중단"되어 데이터베이스가 복구될 때까지 기다립니다. 일하다.

활성 테스트를 선언했다면 데이터베이스가 손상되고 활성 테스트가 실패하여 Kubernetes에서 모든 것의 절반이 다시 시작된다고 상상해 보세요. 이는 다시 시작해야 함을 의미합니다. 이것은 당신이 원하는 것이 전혀 아닙니다. 실제로 개인적인 경험도있었습니다. JS로 작성되어 Mongo 데이터베이스에 제공되는 채팅 애플리케이션이 있었습니다. 문제는 Kubernetes 작업을 시작할 때 Kubernetes가 할 수 있다는 원칙에 따라 테스트의 준비 상태와 활성 상태를 설명했기 때문에 이를 사용할 것이라는 것입니다. 따라서 어느 시점부터 Mongo는 약간 "무뎌지고" 샘플이 실패하기 시작했습니다. 따라서 비가 내리는 테스트에 따르면 꼬투리가 "죽이기"시작했습니다.

아시다시피, 그들이 "죽으면" 이것은 채팅입니다. 즉, 클라이언트로부터 많은 연결이 걸려 있습니다. 그들은 또한 "죽었습니다" - 아니요, 클라이언트가 아니라 연결만 가능합니다 - 동시에 모두 죽지 않으며 동시에 죽지 않기 때문에 일부는 더 일찍, 일부는 나중에 동시에 시작되지 않습니다. 시간. 게다가 표준 무작위를 사용하면 매번 애플리케이션 시작 시간을 밀리초 단위로 정확하게 예측할 수 없으므로 한 번에 한 인스턴스씩 수행합니다. 하나의 Infospot이 올라가고 밸런싱에 추가되고 모든 클라이언트가 거기로 오며 혼자이기 때문에 그러한 부하를 견딜 수 없으며 대략적으로 말하면 거기에서 일하는 수십 명이 있고 넘어집니다. 다음 사람이 일어나고 모든 짐이 그에게 있고 그도 넘어집니다. 음, 이 폭포들은 계속 계단식으로 쏟아져 나옵니다. 결국 이 문제가 해결된 방법은 이 애플리케이션에 대한 사용자 트래픽을 엄격하게 중지하고 모든 인스턴스가 상승하도록 한 다음 모든 사용자 트래픽을 한 번에 시작하여 이미 XNUMX개의 인스턴스 모두에 분산되도록 해야 했습니다.

이 활성 테스트가 발표되어 모든 것이 다시 시작되지 않았다면 애플리케이션은 이를 잘 처리했을 것입니다. 그러나 데이터베이스에 액세스할 수 없고 모든 사용자가 "탈락"했기 때문에 균형 조정의 모든 것이 비활성화되었습니다. 그런 다음 이 데이터베이스를 사용할 수 있게 되면 모든 것이 밸런싱에 포함되지만 애플리케이션을 다시 시작할 필요가 없으며 이에 시간과 리소스를 낭비할 필요가 없습니다. 그들은 모두 이미 여기에 있고 트래픽 준비가 되어 있으므로 트래픽이 열리고 모든 것이 정상입니다. 애플리케이션이 제자리에 있고 모든 것이 계속 작동합니다.

따라서 준비 상태 테스트와 활동성 테스트는 다릅니다. 더욱이 이론적으로 서로 다른 상태 확인(예: 한 가지 유형의 radii, 한 가지 유형의 liv)을 수행하고 다른 항목을 확인할 수 있습니다. 준비 테스트 중에 백엔드를 확인하세요. 예를 들어, 활성 테스트에서는 활성 테스트가 일반적으로 응답할 수 있는 애플리케이션일 뿐이라는 관점에서 확인하지 않습니다.

왜냐하면 생체 테스트는 대체로 우리가 "갇힌" 상태이기 때문입니다. 무한 루프 또는 기타 문제가 시작되었으며 더 이상 요청이 처리되지 않습니다. 따라서 이들을 분리하고 서로 다른 논리를 구현하는 것이 합리적입니다.

테스트할 때, 건강검진할 때 답변해야 할 사항에 대해. 정말 고통 스럽습니다. 이것에 익숙한 사람들은 아마 웃을 것입니다. 그러나 진지하게, 나는 200%의 경우에 "XNUMX"이라고 대답하는 서비스를 내 인생에서 본 적이 있습니다. 즉, 누가 성공했는가입니다. 그러나 동시에 그들은 응답 본문에 "이러한 오류"라고 적습니다.

즉, 응답 상태가 표시됩니다. 모든 것이 성공했습니다. 하지만 동시에 본문을 구문 분석해야 합니다. 본문에서는 "죄송합니다. 요청이 오류로 종료되었습니다"라고 말하고 이것이 현실일 뿐입니다. 나는 이것을 실생활에서 보았다.

그리고 어떤 사람들은 그것이 재미있다고 생각하지 않고 다른 사람들은 그것이 매우 고통스럽다고 생각하므로 여전히 간단한 규칙을 고수할 가치가 있습니다. 상태 확인 및 원칙적으로 웹 애플리케이션 작업 시.

모든 것이 잘 되었다면 204번째 답변으로 응답하세요. 원칙적으로 5분의 10의 답변이 귀하에게 적합합니다. ragsy를 잘 읽고 일부 응답 상태가 다른 응답 상태와 다르다는 것을 알고 있다면 적절한 응답 상태(15, 502, XNUMX, XNUMX 등)로 답하십시오. 별로 좋지 않다면 그냥 "XNUMX"이면 됩니다. 모든 것이 잘못되고 상태 점검이 응답하지 않으면 XNUMX분의 XNUMX로 대답하십시오. 다시 말하지만, 응답 방법을 이해하면 응답 상태가 어떻게 다른지 알 수 있습니다. 이해가 되지 않는다면 문제가 발생할 경우 상태 확인에 응답하기 위한 XNUMX번 옵션을 선택하세요.

이것은 또 다른 요점입니다. 기본 서비스 확인에 대해 조금 돌아가고 싶습니다. 예를 들어, 애플리케이션 뒤에 있는 모든 기본 서비스(일반적으로 모든 것)를 검사하기 시작하면 마이크로서비스 아키텍처의 관점에서 우리는 "낮은 결합", 즉 서비스가 서로 최소한으로 의존하는 개념을 가지고 있습니다. 그 중 하나가 실패하면 이 기능이 없는 다른 모든 기능은 계속 작동합니다. 일부 기능이 작동하지 않습니다. 따라서 모든 상태 확인을 서로 연결하면 결국 인프라에서 한 가지가 떨어지게 되며, 그것이 떨어지기 때문에 모든 서비스의 모든 상태 확인도 실패하기 시작합니다. 전체 마이크로서비스 아키텍처 No. 그곳에서는 모든 것이 어두워졌습니다.

따라서 기본 서비스를 확인해야 한다는 점을 다시 반복하고 싶습니다. 이 서비스가 없으면 애플리케이션이 XNUMX%의 경우 제 역할을 할 수 없습니다. 즉, 사용자가 데이터베이스에 저장하거나 데이터베이스에서 검색하는 데 사용하는 REST API가 있는 경우 데이터베이스가 없으면 사용자와의 작업을 보장할 수 없다는 것이 논리적입니다.

그러나 사용자를 데이터베이스에서 꺼낼 때 프런트엔드에 응답을 보내기 전에 입력한 다른 백엔드의 다른 메타데이터가 추가로 풍부해지고 이 백엔드를 사용할 수 없는 경우 이는 메타데이터의 일부 없이 답변하세요.

다음으로, 애플리케이션을 시작할 때 발생하는 고통스러운 문제 중 하나도 있습니다.

사실 이는 대체로 쿠버네티스에만 적용되는 것이 아니라, 일종의 대규모 개발, 특히 데브옵스(DevOps) 문화가 쿠버네티스와 같은 시기에 확산되기 시작한 것도 우연이었다. 따라서 전반적으로 Kubernetes 없이 애플리케이션을 정상적으로 종료해야 하는 것으로 나타났습니다. 쿠버네티스 이전에도 사람들은 이런 일을 했지만, 쿠버네티스가 등장하면서 우리는 이에 대해 집단적으로 이야기하기 시작했습니다.

정상적인 종료

일반적으로 Graceful Shutdown은 무엇이며 왜 필요한가요? 이것은 어떤 이유로 인해 애플리케이션이 충돌하는 경우에 대한 것입니다. app stop - 또는 예를 들어 운영 체제로부터 신호를 받으면 애플리케이션이 이를 이해하고 이에 대해 조치를 취해야 합니다. 물론 최악의 시나리오는 애플리케이션이 SIGTERM을 수신하고 "SIGTERM, 조금만 기다려, 작업하고 아무것도 하지 마세요."와 같은 경우입니다. 이것은 완전히 나쁜 선택입니다.

거의 똑같이 나쁜 옵션은 애플리케이션이 SIGTERM을 수신하고 "그들이 segterm이라고 말했는데, 그건 우리가 끝났다는 뜻입니다. 본 적도 없고, 어떤 사용자 요청도 모르고, 어떤 종류의 요청인지 모르겠습니다."라고 말하는 경우입니다. 지금 작업 중인 요청이 SIGTERM이라고 하더군요. 즉, 우리가 종료된다는 의미입니다." 이것은 또한 나쁜 선택입니다.

어떤 옵션이 좋은가요? 첫 번째 요점은 작업 완료를 고려하는 것입니다. 좋은 옵션은 서버가 SIGTERM을 수신하는 경우 수행할 작업을 계속 고려하는 것입니다.

SIGTERM은 소프트 종료이며 특별히 설계되었으며 코드 수준에서 가로챌 수 있고 처리될 수 있습니다. 이제 잠깐만요. 먼저 작업을 마친 다음 종료할 것입니다.

Kubernetes 관점에서 보면 다음과 같습니다. Kubernetes 클러스터에서 실행 중인 Pod에 "중지하세요. 저리 가세요"라고 말하거나 다시 시작되거나 Kubernetes가 Pod를 다시 생성할 때 업데이트가 발생하면 Kubernetes는 동일한 SIGTERM 메시지를 Pod에 보내고 기다립니다. 그리고 이것은 그가 기다리는 시간이며 또한 구성되어 있으며 졸업장에는 Graceful ShutdownTimeout이라고 불리는 특별한 매개 변수가 있습니다. 아시다시피, 그것은 아무것도 아닌 것이 아니며 지금 우리가 그것에 대해 이야기하는 것도 아무것도 아닙니다.

여기에서 우리는 SIGTERM을 애플리케이션에 보내는 시간과 애플리케이션이 무언가에 미쳐버린 것 같거나 "멈춰" 있고 끝나지 않을 것이라는 것을 이해하는 시간 사이에 얼마나 오래 기다려야 하는지 구체적으로 말할 수 있습니다. SIGKILL을 보내십시오. 즉, 작업을 열심히 완료하십시오. 즉, 일종의 데몬이 실행되고 작업을 처리합니다. 우리는 데몬이 수행하는 작업이 평균적으로 한 번에 30초 이상 지속되지 않는다는 것을 알고 있습니다. 따라서 SIGTERM이 도착하면 데몬이 SIGTERM 이후 최대 30초 후에 완료될 수 있다는 것을 이해합니다. 예를 들어 만약을 대비해 45초라고 쓰고 SIGTERM이라고 말합니다. 그 후 45초를 기다립니다. 이론적으로 이 기간 동안 악마는 자신의 작업을 완료하고 자체적으로 종료되어야 합니다. 하지만 갑자기 처리할 수 없다면, 멈춰 있을 가능성이 높습니다. 더 이상 요청을 정상적으로 처리하지 못하고 있다는 의미입니다. 그리고 45초 안에 그를 안전하게 처형할 수 있습니다.

실제로 여기에서는 두 가지 측면도 고려할 수 있습니다. 첫째, 요청을 받은 경우 어떻게든 작업을 시작했고 사용자에게 응답을 제공하지 않았지만 예를 들어 SIGTERM을 받았다는 점을 이해하세요. 이를 개선하고 사용자에게 답변을 제공하는 것이 합리적입니다. 이와 관련하여 이것이 첫 번째 요점입니다. 여기서 두 번째 요점은 자신의 애플리케이션을 작성하는 경우 일반적으로 애플리케이션에 대한 요청을 받은 다음 일부 작업을 시작하고 어딘가에서 파일 다운로드를 시작하고 데이터베이스를 다운로드하는 등의 방식으로 아키텍처를 구축한다는 것입니다. 저것. 일반적으로 사용자의 요청은 2분 동안 중단되고 사용자가 응답할 때까지 기다립니다. 그런 다음 아키텍처 작업이 필요할 가능성이 높습니다. 즉, 작업이 짧다면 SIGTERM을 무시하고 수정하는 것이 합리적이라는 상식까지 고려하세요. 작업이 길면 이 경우 SIGTERM을 무시하는 것이 의미가 없습니다. 이러한 긴 작업을 피하기 위해 아키텍처를 다시 설계하는 것이 합리적입니다. 사용자가 그냥 기다리지 않도록 말이죠. 모르겠어요, 거기에 어떤 종류의 웹소켓을 만들고, 서버가 이미 클라이언트에 보낼 리버스 후크를 만드세요. 하지만 사용자가 XNUMX분 동안 기다리도록 강요하지 말고 세션이 끝날 때까지 기다리세요. 그에게 대답해 보세요. 어디서 깨질지 예측할 수 없기 때문입니다.

애플리케이션이 종료되면 적절한 종료 코드를 제공해야 합니다. 즉, 애플리케이션을 닫고 중지하라는 요청을 받고 정상적으로 스스로 중지할 수 있는 경우 일종의 종료 코드 1,5,255 등을 반환할 필요가 없습니다. 적어도 Linux 시스템에서는 코드가 0이 아닌 모든 것은 실패한 것으로 간주됩니다. 즉, 이 경우 귀하의 신청이 오류로 종료된 것으로 간주됩니다. 따라서 우호적으로 애플리케이션이 오류 없이 완료되면 출력에 0이 표시됩니다. 어떤 이유로든 애플리케이션이 실패하면 출력에 non-XNUMX이 표시됩니다. 그리고 이 정보를 가지고 작업할 수 있습니다.

그리고 마지막 옵션. 사용자가 요청을 보내고 이를 처리하는 동안 XNUMX분 동안 멈추는 것은 좋지 않습니다. 그러나 일반적으로 고객 측에서 일반적으로 가치가 있는 것이 무엇인지에 대해서도 말씀드리고 싶습니다. 모바일 애플리케이션, 프런트 엔드 등이 있는지는 중요하지 않습니다. 일반적으로 사용자 세션이 종료될 수 있으며 어떤 일이 발생할 수 있다는 점을 고려해야 합니다. 예를 들어 요청이 제대로 처리되지 않아 응답이 반환되지 않은 채 전송될 수 있습니다. 귀하의 프런트엔드 또는 모바일 애플리케이션(일반적으로 모든 프런트엔드를 그렇게 표현하겠습니다)은 이를 고려해야 합니다. 웹소켓으로 작업한다면 이것은 일반적으로 제가 겪은 최악의 고통입니다.

일부 일반 채팅의 개발자가 이를 알지 못하는 경우 웹소켓이 중단될 수 있는 것으로 나타났습니다. 이들의 경우 프록시에 문제가 발생하면 구성을 변경하기만 하면 다시 로드됩니다. 당연히 이 경우 모든 장기 세션이 중단됩니다. 개발자들이 우리에게 달려와서 이렇게 말합니다. "얘들아, 뭐 하는 거야? 모든 클라이언트의 채팅이 중단됐어!" 우리는 그들에게 이렇게 말합니다. “뭐하는 거예요? 클라이언트가 다시 연결할 수 없습니까? 그들은 "아니요. 세션이 찢어지지 않도록 해야 합니다."라고 말합니다. 간단히 말해서 이것은 실제로 말도 안되는 일입니다. 클라이언트 측을 고려해야 합니다. 특히 웹소켓과 같이 오래 지속되는 세션의 경우 세션이 중단될 수 있으며 사용자가 눈치 채지 못하는 경우 이러한 세션을 다시 설치할 수 있어야 합니다. 그러면 모든 것이 완벽해집니다.

리소스

사실 여기서는 솔직한 이야기만 들려드리겠습니다. 다시 실생활에서. 자원에 관해 들어본 것 중 가장 역겹습니다.

이 경우 리소스는 Kubernetes 클러스터의 포드에 넣을 수 있는 일종의 요청, 제한을 의미합니다. 개발자에게 들은 가장 웃긴 말은... 이전 직장 동료 개발자 중 한 명이 "내 애플리케이션이 클러스터에서 시작되지 않습니다."라고 말한 적이 있습니다. 시작되지 않는지 살펴봤지만 리소스에 맞지 않거나 아주 작은 제한을 설정했습니다. 즉, 리소스로 인해 애플리케이션을 시작할 수 없습니다. 나는 "자원 때문에 시작되지 않을 것입니다. 필요한 양을 결정하고 적절한 값을 설정하십시오."라고 말합니다. 그는 "어떤 종류의 자원이요?"라고 말합니다. 나는 그에게 Kubernetes, 요청 제한 및 어쩌고 저쩌고 설정해야 한다고 설명하기 시작했습니다. 그 남자는 XNUMX분 동안 듣고 고개를 끄덕이며 이렇게 말했습니다. “저는 개발자로 일하기 위해 여기에 왔고 어떤 자원에 대해서도 알고 싶지 않습니다. 나는 코드를 작성하기 위해 여기에 왔고 그게 전부입니다.” 슬프다. 개발자 입장에서는 매우 안타까운 개념입니다. 특히 현대 세계에서는 진보적인 데브옵(devops)이 그렇습니다.

자원이 왜 필요한가요? Kubernetes에는 두 가지 유형의 리소스가 있습니다. 일부는 요청이라고 하고 다른 일부는 제한이라고 합니다. 자원을 통해 우리는 기본적으로 항상 두 가지 기본 제한 사항만 있음을 이해할 것입니다. 즉, Kubernetes에서 실행되는 컨테이너에 대한 CPU 시간 제한 및 RAM 제한입니다.

제한은 애플리케이션에서 리소스를 사용할 수 있는 방법에 대한 상한을 지정합니다. 즉, 제한에 1GB의 RAM이 있다고 말하면 애플리케이션은 1GB 이상의 RAM을 사용할 수 없습니다. 그리고 그가 갑자기 이것을 원하고 시도하면 oom killer라는 프로세스가 메모리 부족, 즉 응용 프로그램을 종료하고 종료합니다. 즉, 간단히 다시 시작됩니다. 애플리케이션은 CPU에 따라 다시 시작되지 않습니다. CPU의 경우, 응용 프로그램이 제한에 지정된 것보다 많이 사용하려고 하면 단순히 CPU가 엄격하게 선택됩니다. 이로 인해 다시 시작되지는 않습니다. 이것이 한계입니다. 이것이 상한입니다.

그리고 부탁이 있습니다. 요청은 Kubernetes가 Kubernetes 클러스터의 노드가 애플리케이션으로 채워지는 방식을 이해하는 방법입니다. 즉, 요청은 애플리케이션에 대한 일종의 커밋입니다. 내가 사용하고 싶은 것이 무엇인지 적혀 있습니다. “이 정도의 CPU와 이 정도의 메모리를 예약해 주세요.” 정말 간단한 비유입니다. 총 8개의 CPU가 있는 노드가 있다면 어떨까요? 그리고 요청에 CPU 1개가 있는 Pod가 도착합니다. 이는 노드에 CPU가 7개 남아 있음을 의미합니다. 즉, 각각의 요청에 8개의 CPU가 있는 1개의 포드가 이 노드에 도착하자마자 마치 Kubernetes의 관점에서 노드의 CPU가 부족해 요청이 있는 더 많은 포드를 처리할 수 없습니다. 이 노드에서 시작되었습니다. 모든 노드에 CPU가 부족하면 Kubernetes는 CPU가 부족하기 때문에 클러스터에 Pod를 실행하기에 적합한 노드가 없다고 말하기 시작합니다.

요청이 필요한 이유는 무엇이며 요청이 없으면 Kubernetes에서 아무것도 시작할 필요가 없다고 생각하는 이유는 무엇입니까? 가상의 상황을 상상해 봅시다. 요청 없이 애플리케이션을 시작하면 Kubernetes는 사용자가 보유한 항목의 양, 이를 푸시할 수 있는 노드를 알지 못합니다. 글쎄, 그는 노드를 밀고, 밀고, 밀었습니다. 어느 시점에서 애플리케이션에 트래픽이 발생하기 시작합니다. 그리고 응용 프로그램 중 하나가 갑자기 제한에 따른 제한까지 리소스를 사용하기 시작합니다. 근처에 다른 애플리케이션이 있고 리소스도 필요하다는 것이 밝혀졌습니다. 실제로 노드에는 OP와 같은 리소스가 물리적으로 부족해지기 시작합니다. 실제로 노드에는 RAM(Random Access Memory)과 같은 리소스가 물리적으로 부족해지기 시작합니다. 노드의 전원이 부족해지면 먼저 docker가 응답을 멈추고 그 다음에는 큐블렛, OS가 응답을 멈춥니다. 그들은 단순히 의식을 잃을 것이고 모든 것이 확실히 당신을 위해 작동하지 않을 것입니다. 즉, 이로 인해 노드가 중단되고 다시 시작해야 합니다. 한마디로 상황이 별로 좋지 않다.

그리고 요청이 있을 때 제한은 크게 다르지 않으며 적어도 제한이나 요청보다 몇 배는 많지 않습니다. 그러면 Kubernetes 클러스터 노드 전체에 걸쳐 정상적이고 합리적인 애플리케이션 채우기를 가질 수 있습니다. 동시에 Kubernetes는 어디에 무엇을 얼마나 두고, 어디에 무엇을 사용하는지 대략적으로 알고 있습니다. 즉, 바로 그런 순간이다. 그것을 이해하는 것이 중요합니다. 그리고 이것이 표시되도록 제어하는 ​​것이 중요합니다.

데이터 저장

다음 요점은 데이터 저장에 관한 것입니다. 그것들로 무엇을 해야 하며 일반적으로 Kubernetes의 지속성으로 무엇을 해야 합니까?

내 생각엔 다시 우리 내부에서 저녁 학교, Kubernetes의 데이터베이스에 관한 주제가 있었습니다. 그리고 동료들이 “Kubernetes에서 데이터베이스를 실행할 수 있습니까?”라는 질문을 받았을 때 어떤 말을 했는지 대략적으로도 알 것 같습니다. 어떤 이유에서인지, 당신의 동료들이 쿠버네티스에서 데이터베이스를 실행하는 것이 가능한지 묻는다면 불가능하다고 말했어야 했던 것 같습니다.

여기서의 논리는 간단합니다. 만일을 대비해 다시 한 번 설명하겠습니다. 분산 네트워크 스토리지의 내결함성 시스템을 구축할 수 있는 정말 멋진 사람이라면 이 경우에 데이터베이스를 맞추는 방법과 컨테이너의 클라우드 네이티브가 어떻게 작동해야 하는지 이해하세요. 일반적으로 데이터베이스에서. 아마도 실행 방법에 대해서는 의문의 여지가 없습니다. 그러한 질문이 있고 모든 것이 펼쳐지고 생산 과정에서 바로 세워지고 절대 떨어지지 않는지 확인하고 싶다면 이런 일이 발생하지 않습니다. 이 접근 방식을 사용하면 발에 총을 쏠 수 있습니다. 그러니 하지 않는 것이 좋습니다.

애플리케이션이 저장하려는 데이터, 사용자가 업로드하는 일부 사진, 애플리케이션이 작동하는 동안(예: 시작 시) 생성하는 일부 항목으로 무엇을 해야 할까요? Kubernetes에서 이를 어떻게 처리해야 할까요?

일반적으로 이상적으로는 물론입니다. Kubernetes는 매우 잘 설계되었으며 일반적으로 처음에는 상태 비저장 애플리케이션용으로 고안되었습니다. 즉, 정보를 전혀 저장하지 않는 애플리케이션의 경우입니다. 이것이 이상적입니다.

그러나 물론 이상적인 선택이 항상 존재하는 것은 아닙니다. 그래서 뭐? 첫 번째이자 가장 간단한 요점은 집에서 만든 것이 아니라 작동 방식도 불분명하지만 일부 공급자가 제공하는 일종의 S3를 사용하는 것입니다. 훌륭하고 정상적인 공급자이며 애플리케이션에 S3를 사용하도록 가르칩니다. 즉, 사용자가 파일을 업로드하고 싶을 때 "여기서 S3에 업로드해 주세요."라고 말합니다. 그가 그것을 받고 싶을 때, "여기 S3로 돌아가는 링크가 있으니 여기에서 가져가세요."라고 말하세요. 이것이 이상적입니다.

어떤 이유로 갑자기 이 이상적인 옵션이 적합하지 않거나 작성하지 않았거나 개발하지 않은 애플리케이션이 있거나 일종의 끔찍한 유산인 경우 S3 프로토콜을 사용할 수 없지만 로컬 디렉터리와 함께 작동해야 합니다. 로컬 폴더. 다소 간단한 작업을 통해 Kubernetes를 배포해 보세요. 즉, 최소한의 작업을 위해 Ceph를 즉시 펜싱하는 것은 나쁜 생각인 것 같습니다. 물론 Ceph는 훌륭하고 패셔너블하기 때문입니다. 하지만 자신이 하고 있는 일을 실제로 이해하지 못한다면 일단 Ceph에 무언가를 넣으면 아주 쉽게 다시는 꺼내지 못할 수 있습니다. 아시다시피 Ceph는 클러스터에 데이터를 단순 파일 형식이 아닌 바이너리 형식으로 저장하기 때문입니다. 따라서 갑자기 Ceph 클러스터가 중단되면 다시는 Ceph 클러스터에서 데이터를 가져오지 못할 가능성이 완전하고 높습니다.

우리는 Ceph에 대한 강좌를 가질 것입니다. 프로그램을 숙지하고 신청서를 제출하세요..

따라서 NFS 서버처럼 간단한 작업을 수행하는 것이 좋습니다. Kubernetes는 이들과 함께 작업할 수 있으며 NFS 서버 아래에 디렉터리를 마운트할 수 있습니다. 애플리케이션은 로컬 디렉터리와 같습니다. 동시에, 당연히 NFS로 뭔가를 해야 한다는 점을 이해해야 하며 때로는 액세스할 수 없게 될 수도 있다는 점을 이해하고 이 경우 무엇을 할 것인지에 대한 질문을 고려해야 합니다. 아마도 별도의 시스템 어딘가에 백업되어야 할 것입니다.

제가 이야기한 다음 요점은 응용 프로그램이 작동 중에 일부 파일을 생성하는 경우 어떻게 해야 하는지에 대한 것입니다. 예를 들어, 시작 시 애플리케이션이 시작 시에만 수신하는 일부 정보를 기반으로 하는 일부 정적 파일을 생성합니다. 정말 순간입니다. 그러한 데이터가 많지 않으면 전혀 귀찮게 할 필요가 없습니다. 이 응용 프로그램을 직접 설치하고 작업하십시오. 여기서 유일한 질문은 무엇입니까? WordPress 등과 같은 모든 종류의 레거시 시스템, 특히 영리한 플러그인을 수정한 영리한 PHP 개발자를 사용하여 스스로 일종의 파일을 생성하도록 만드는 방법을 알고 있는 경우가 많습니다. 따라서 하나는 하나의 파일을 생성하고 두 번째는 두 번째 파일을 생성합니다. 그들은 다르다. 균형은 클라이언트의 Kubernetes 클러스터에서 우연히 발생합니다. 따라서 그들은 예를 들어 함께 일하는 방법을 모르는 것으로 나타났습니다. 하나는 하나의 정보를 제공하고 다른 하나는 사용자에게 다른 정보를 제공합니다. 이것은 피해야 할 것입니다. 즉, Kubernetes에서는 실행하는 모든 것이 여러 인스턴스에서 작동할 수 있도록 보장됩니다. Kubernetes는 움직이는 것이기 때문입니다. 따라서 그는 누구에게도 묻지 않고도 원할 때마다 무엇이든 옮길 수 있습니다. 그러므로 이것을 믿을 필요가 있습니다. 한 인스턴스에서 시작된 모든 것은 조만간 실패할 것입니다. 예약은 많을수록 좋습니다. 그러나 다시 한 번 말하지만, 그러한 파일이 몇 개 있으면 바로 아래에 놓을 수 있으며 무게는 적습니다. 조금 더 있으면 용기 안으로 밀어 넣으면 안 됩니다.

Kubernetes에는 볼륨을 사용할 수 있는 멋진 기능이 있다고 조언하고 싶습니다. 특히, 빈 dir 유형의 볼륨이 있습니다. 즉, Kubernetes는 사용자가 시작한 서버의 서비스 디렉터리에 디렉터리를 자동으로 생성합니다. 그리고 그분은 당신이 그것을 사용할 수 있도록 그것을 당신에게 주실 것입니다. 중요한 점은 하나뿐입니다. 즉, 데이터는 컨테이너 내부에 저장되지 않고 실행 중인 호스트에 저장됩니다. 또한 Kubernetes는 일반 구성에서 이러한 빈 디렉토리를 제어할 수 있으며 최대 크기를 제어하고 이를 초과하는 것을 허용하지 않습니다. 유일한 요점은 빈 디렉토리에 작성한 내용이 포드를 다시 시작하는 동안 손실되지 않는다는 것입니다. 즉, Pod가 실수로 떨어졌다가 다시 올라가면 빈 디렉토리의 정보는 아무데도 가지 않습니다. 그는 새로운 시작에서 그것을 다시 사용할 수 있고 그것은 좋습니다. 귀하의 포드가 어딘가로 떠나면 당연히 데이터도 없이 떠날 것입니다. 즉, 빈 dir로 시작된 노드의 Pod가 사라지자마자 빈 dir이 삭제됩니다.

빈 디렉토리의 또 다른 장점은 무엇입니까? 예를 들어 캐시로 사용할 수 있습니다. 우리 애플리케이션이 즉석에서 무언가를 생성하고, 이를 사용자에게 제공하고, 오랫동안 수행한다고 상상해 봅시다. 따라서 예를 들어 애플리케이션은 이를 생성하여 사용자에게 제공하는 동시에 어딘가에 저장하므로 다음에 사용자가 동일한 것을 위해 올 때 즉시 생성하여 제공하는 것이 더 빠를 것입니다. 빈 디렉토리를 Kubernetes에 요청하여 메모리에 생성할 수 있습니다. 따라서 캐시는 일반적으로 디스크 액세스 속도 측면에서 매우 빠른 속도로 작동할 수 있습니다. 즉, 메모리에 빈 디렉토리가 있고 OS에서는 메모리에 저장되지만 Pod 내부의 사용자에게는 로컬 디렉토리처럼 보입니다. 특별히 마술을 가르치기 위해 앱이 필요하지 않습니다. 파일을 직접 가져와 디렉토리에 넣기만 하면 됩니다. 실제로는 OS의 메모리에 있습니다. 이는 쿠버네티스 측면에서도 매우 편리한 기능이다.

미니오에는 어떤 문제가 있나요? Minio의 가장 큰 문제점은 이 기능이 작동하려면 어딘가에서 실행되고 있어야 하며 일종의 파일 시스템, 즉 스토리지가 있어야 한다는 것입니다. 그리고 여기서 우리는 Ceph와 동일한 문제에 직면합니다. 즉, Minio는 파일을 어딘가에 저장해야 합니다. 이는 단순히 파일에 대한 HTTP 인터페이스입니다. 더욱이 기능은 Amazon S3에 비해 확실히 떨어집니다. 이전에는 사용자에게 제대로 권한을 부여할 수 없었습니다. 이제 제가 아는 한 이미 다른 인증을 사용하여 버킷을 생성할 수 있지만, 다시 말해 주요 문제는 말하자면 최소한 기본 스토리지 시스템인 것 같습니다.

메모리의 빈 디렉토리는 제한에 어떤 영향을 줍니까? 어떤 식으로든 한도에 영향을 미치지 않습니다. 이는 컨테이너의 메모리가 아닌 호스트의 메모리에 있습니다. 즉, 컨테이너는 메모리의 빈 디렉토리를 점유된 메모리의 일부로 보지 않습니다. 호스트가 이것을 봅니다. 따라서, 네, 쿠버네티스의 관점에서 이것을 사용하기 시작하면 메모리의 일부를 dir을 비우는 데 할애하고 있다는 점을 이해하는 것이 좋을 것입니다. 따라서 응용 프로그램뿐만 아니라 누군가가 이러한 빈 디렉토리에 쓰기 때문에 메모리가 부족할 수 있다는 점을 이해하십시오.

클라우드 고유성

마지막 하위 주제는 Cloudnative가 무엇인지입니다. 왜 필요한가요? 클라우드 네이티브성 등.

즉, 최신 클라우드 인프라에서 작동할 수 있고 작성되는 애플리케이션입니다. 하지만 사실 클라우드네이티브에는 그런 측면이 또 있습니다. 이는 최신 클라우드 인프라의 모든 요구 사항을 고려할 뿐만 아니라 이 최신 클라우드 인프라를 사용하는 방법도 알고 있는 애플리케이션이므로 이러한 클라우드에서 작동한다는 사실의 장단점을 활용하세요. 너무 과하게 클라우드에서 작업하지 말고 클라우드 작업의 이점을 활용하세요.

Kubernetes를 예로 들어보겠습니다. 애플리케이션이 Kubernetes에서 실행 중입니다. 귀하의 애플리케이션은 언제든지, 또는 오히려 애플리케이션 관리자가 항상 서비스 계정을 생성할 수 있습니다. 즉, 서버에 있는 Kubernetes 자체의 인증을 위한 계정입니다. 거기에 필요한 몇 가지 권한을 추가하세요. 그리고 애플리케이션 내에서 Kubernetes에 액세스할 수 있습니다. 이렇게 하면 무엇을 할 수 있나요? 예를 들어, 애플리케이션에서 다른 애플리케이션과 유사한 인스턴스가 있는 위치에 대한 데이터를 수신하고, 필요한 경우 어떻게든 Kubernetes 위에 함께 클러스터링합니다.

다시 말하지만, 최근에 문자 그대로 사건이 발생했습니다. 대기열을 모니터링하는 컨트롤러가 하나 있습니다. 그리고 이 대기열에 새로운 작업이 나타나면 Kubernetes로 이동하고 Kubernetes 내부에서 새 포드를 생성합니다. 이 Pod에 몇 가지 새로운 작업을 제공하고 이 Pod의 프레임워크 내에서 Pod는 작업을 수행하고 컨트롤러 자체에 응답을 보내고 컨트롤러는 이 정보를 사용하여 작업을 수행합니다. 예를 들어 데이터베이스를 추가합니다. 즉, 이는 우리 애플리케이션이 Kubernetes에서 실행된다는 사실의 장점입니다. 우리는 애플리케이션의 기능을 어떻게든 확장하고 더욱 편리하게 만들기 위해 내장된 Kubernetes 기능 자체를 사용할 수 있습니다. 즉, 애플리케이션을 시작하는 방법, 작업자를 시작하는 방법에 대한 일종의 마법을 숨기지 마십시오. Kubernetes에서는 애플리케이션이 Python으로 작성된 경우 앱에서 요청을 보내기만 하면 됩니다.

Kubernetes를 넘어서는 경우에도 마찬가지입니다. Kubernetes가 어딘가에서 실행되고 있습니다. 일종의 클라우드에 있으면 좋습니다. 다시 한번 말하지만, 우리가 실행 중인 클라우드 자체의 기능을 사용할 수 있고 사용해야 한다고 생각합니다. 클라우드가 우리에게 제공하는 기본적인 것들부터. 밸런싱, 즉 클라우드 밸런서를 생성하여 사용할 수 있습니다. 이것이 우리가 사용할 수 있는 것의 직접적인 이점입니다. 첫째, 클라우드 밸런싱은 작동 방식, 구성 방식에 대한 책임을 어리석게 제거하기 때문입니다. 게다가 일반 Kubernetes는 클라우드와 통합될 수 있기 때문에 매우 편리합니다.

스케일링도 마찬가지다. 일반 Kubernetes는 클라우드 제공업체와 통합할 수 있습니다. 클러스터에 노드가 부족한 경우, 즉 노드 공간이 부족한 경우 추가해야 한다는 점을 이해하는 방법을 알고 있습니다. Kubernetes 자체가 클러스터에 새 노드를 추가하고 해당 노드에서 포드를 시작하기 시작합니다. 즉, 부하가 오면 난로의 수가 증가하기 시작합니다. 이러한 포드에 대한 클러스터의 노드가 부족해지면 Kubernetes는 새 노드를 시작하므로 그에 따라 포드 수가 계속 늘어날 수 있습니다. 그리고 그것은 매우 편리합니다. 이는 즉석에서 클러스터를 확장할 수 있는 직접적인 기회입니다. 그다지 빠르지는 않습니다. XNUMX초가 아니라는 점에서 새 노드를 추가하는 데는 XNUMX분에 가깝습니다.

하지만 내 경험에 따르면, 그것은 내가 본 것 중 가장 멋진 것입니다. Cloudnative 클러스터가 시간을 기준으로 확장된 경우. 백오피스에 있는 사람들이 사용하는 백엔드 서비스였습니다. 즉, 그들은 오전 9시에 출근하여 시스템에 로그인하기 시작하고 그에 따라 모두 실행되고 있는 Cloudnative 클러스터가 부풀어 오르기 시작하여 출근하는 모든 사람이 애플리케이션으로 작업할 수 있도록 새 포드를 시작합니다. 오후 8시 또는 6시에 퇴근하면 Kubernetes 클러스터는 더 이상 애플리케이션을 사용하는 사람이 없다는 것을 알아차리고 크기가 줄어들기 시작합니다. 최대 30%의 절감이 보장됩니다. 당시 아마존에서는 효과가 있었지만 당시 러시아에는 그렇게 잘할 수 있는 사람이 없었습니다.

솔직히 말씀드리자면, Kubernetes를 사용하고 클라우드 기능을 활용하기 때문에 비용이 30% 절감됩니다. 이제 이것은 러시아에서도 가능합니다. 물론 아무에게도 광고하지는 않겠습니다. 하지만 이를 수행할 수 있는 제공업체가 있다고 가정해 보겠습니다. 즉시 버튼을 사용하여 광고를 제공할 수 있습니다.

마지막으로 여러분의 관심을 끌고 싶은 점이 하나 있습니다. 애플리케이션, 인프라가 클라우드 네이티브가 되려면 마침내 코드형 인프라라는 접근 방식을 채택하는 것이 합리적입니다. 즉, 애플리케이션 또는 인프라가 클라우드 네이티브와 정확히 동일한 방식으로 필요하다는 의미입니다. 코드 애플리케이션, 비즈니스 로직을 코드 형식으로 설명하십시오. 코드로 작업합니다. 즉, 테스트하고, 출시하고, git에 저장하고, CICD를 적용합니다.

이것이 바로 귀하가 인프라를 항상 제어하고 현재 상태를 항상 이해할 수 있게 해주는 것입니다. 둘째, 오류를 일으키는 수동 작업을 피하십시오. 셋째, 동일한 수동 작업을 지속적으로 수행해야 하는 경우 단순히 이직률을 피하십시오. 넷째, 장애 발생 시 훨씬 빠르게 복구할 수 있습니다. 러시아에서는 내가 이 문제에 대해 이야기할 때마다 “그래, 분명하지만 접근 방식이 있으니 간단히 말해서 아무것도 고칠 필요가 없어”라고 말하는 사람들이 엄청나게 많습니다. 하지만 사실이에요. 인프라에 문제가 있는 경우 Cloudnative 접근 방식의 관점과 코드형 인프라의 관점에서 보면 이를 수정하는 것보다 서버에 가서 문제가 있는 부분을 찾아 수정하는 것이 더 쉽습니다. 서버를 삭제하고 다시 생성하세요. 그리고 나는 이 모든 것을 회복할 것이다.

이러한 모든 문제는 다음에서 더 자세히 논의됩니다. Kubernetes 비디오 과정: 주니어, 기본, 메가. 링크를 따라가시면 프로그램과 조건을 숙지하실 수 있습니다. 편리한 점은 집이나 직장에서 하루 1~2시간씩 공부하면 쿠버네티스를 마스터할 수 있다는 점이다.

출처 : habr.com