쿠버네티스가 세계를 장악할 것입니다. 언제 어떻게?

기대하면서 DevOpsConf 비탈리 하바로프 인터뷰한 드미트리 스톨야로프 (디스톨), Flant 회사의 기술 이사이자 공동 창립자입니다. Vitaly는 Dmitry에게 Flant가 하는 일, Kubernetes, 생태계 개발, 지원에 대해 물었습니다. Kubernetes가 필요한 이유와 그것이 필요한지 여부에 대해 논의했습니다. 또한 마이크로서비스, Amazon AWS, DevOps에 대한 "I'll be Lucky" 접근 방식, Kubernetes 자체의 미래, 이것이 왜, 언제, 어떻게 세계를 장악할 것인지, DevOps의 전망과 엔지니어들이 클라우드 환경에서 무엇을 준비해야 하는지에 대해 설명합니다. 단순화와 신경망을 통한 밝고 가까운 미래.

원본 인터뷰 DevOps에 관한 러시아어 팟캐스트인 DevOps Deflop에서 팟캐스트를 들어보세요. 아래는 텍스트 버전입니다.

여기와 아래에서 그는 질문을 합니다. 비탈리 하바로프 Express42의 엔지니어.

"플랜트"에 대하여

- 안녕하세요 디마. 당신은 기술 이사입니다 "플란트"이자 창립자이기도 합니다. 회사에서 어떤 일을 하는지, 어떤 일을 하는지 알려주세요.

드미트리: 겉으로 보기에 우리는 모두를 위해 Kubernetes를 설치하고 그것으로 뭔가를 하는 사람들처럼 보입니다. 그러나 그것은 사실이 아닙니다. 우리는 Linux를 다루는 회사로 시작했지만 오랫동안 우리의 주요 활동은 프로덕션 및 고부하 턴키 프로젝트에 서비스를 제공하는 것이었습니다. 일반적으로 우리는 전체 인프라를 처음부터 구축한 다음 오랫동안 책임을 집니다. 따라서 '플랑'이 돈을 받는 주된 업무는 책임을 다하고 턴키 생산을 구현합니다..




저는 기술 이사이자 회사 창립자 중 한 사람으로서 생산의 접근성을 높이고, 운영을 단순화하며, 관리자의 삶을 더 쉽게 만들고, 개발자의 삶을 더 즐겁게 만들 수 있는 방법을 찾기 위해 밤낮없이 노력합니다. .

쿠버네티스 소개

— 최근 플랑(Flant)에서 제보를 많이 봤는데, 조항 쿠버네티스에 대해. 어떻게 여기까지 왔나요?

드미트리: 이 얘기는 이미 여러 번 얘기했지만 다시 말해도 전혀 상관이 없습니다. 원인과 결과 사이에 혼동이 있기 때문에 이 주제를 반복하는 것이 옳다고 생각합니다.

우리에게는 정말 도구가 필요했습니다. 우리는 많은 문제에 직면했고, 어려움을 겪었으며, 다양한 목발로 그것을 극복하고 도구의 필요성을 느꼈습니다. 우리는 다양한 옵션을 검토하고 자체 자전거를 제작하며 경험을 쌓았습니다. 점차적으로 우리는 Docker가 등장하자마자 거의 2013년경에 Docker를 사용하기 시작했습니다. 등장 당시 우리는 이미 컨테이너에 대한 많은 경험을 갖고 있었고 이미 Python으로 우리 자신의 목발 중 일부인 "Docker"와 유사한 것을 작성했습니다. Docker의 출현으로 목발을 버리고 신뢰할 수 있는 커뮤니티 지원 솔루션을 사용할 수 있게 되었습니다.

Kubernetes의 경우 이야기는 비슷합니다. 탄력을 받기 시작했을 때(우리에게는 버전 1.2) 이미 Shell과 Chef 모두에 여러 가지 목발이 있었고 어떻게든 Docker를 사용하여 조율하려고 했습니다. 우리는 Rancher와 기타 다양한 솔루션을 진지하게 고려하고 있었지만 모든 것이 우리가 했던 것과 정확히 같거나 더 나은 방식으로 구현되는 Kubernetes가 나타났습니다. 불평할 것이 없습니다.

예, 여기에는 어떤 종류의 결함이 있고 거기에는 어떤 종류의 결함이 있습니다. 결함이 많고 1.2는 일반적으로 끔찍하지만... Kubernetes는 건설 중인 건물과 같습니다. 프로젝트를 보고 이해합니다. 괜찮을 거라고요. 이제 건물에 기초와 XNUMX층이 있는 경우 아직 입주하지 않는 것이 더 낫다는 것을 이해하지만 소프트웨어에는 그러한 문제가 없습니다. 이미 사용할 수 있습니다.

Kubernetes를 사용할지 말지 고민한 순간은 없었습니다. 우리는 그것이 나타나기 오래 전부터 기다리고 있었고 스스로 아날로그를 만들려고 노력했습니다.

쿠버네티스 소개

— Kubernetes 자체 개발에 직접 참여하시나요?

드미트리: 보통. 오히려 우리는 생태계 발전에 참여합니다. 우리는 Prometheus, 다양한 운영자, Helm, 생태계 등 특정 수의 풀 요청을 보냅니다. 불행하게도 저는 우리가 하는 모든 일을 추적할 수 없으며 제가 틀릴 수도 있지만, 우리가 코어로 연결하는 풀은 하나도 없습니다.

— 동시에 Kubernetes를 중심으로 많은 도구를 개발하시나요?

드미트리: 전략은 다음과 같습니다. 우리는 이미 존재하는 모든 것에 요청을 가져옵니다. 끌어오기 요청이 수락되지 않으면 우리는 이를 직접 포크하고 빌드에서 수락될 때까지 살아갑니다. 그런 다음 업스트림에 도달하면 업스트림 버전으로 돌아갑니다.

예를 들어 Prometheus 연산자가 있는데, 이를 통해 어셈블리 업스트림을 이미 5번 정도 전환했을 것입니다. 일종의 기능이 필요하고 끌어오기 요청을 보냈으며 내일 출시해야 하지만 업스트림에 출시될 때까지 기다리고 싶지 않습니다. 따라서 우리는 스스로 조립하고 어떤 이유로든 필요한 기능을 갖춘 어셈블리를 모든 클러스터에 출시합니다. 그런 다음 예를 들어 "얘들 아, 좀 더 일반적인 경우를 위해 해보자"라는 말로 업스트림에있는 우리에게 그것을 넘깁니다. 우리 또는 다른 사람이 그것을 끝내고 시간이 지남에 따라 다시 병합됩니다.

우리는 존재하는 모든 것을 개발하려고 노력합니다.. 아직 존재하지 않거나, 아직 발명되지 않았거나, 발명되었지만 구현할 시간이 없었던 많은 요소가 우리가 수행하고 있습니다. 우리가 산업으로서의 프로세스나 자전거 제작을 좋아하기 때문이 아니라 단순히 이 도구가 필요하기 때문입니다. 우리는 왜 이런 저런 일을 했는가라는 질문을 자주 받습니다. 대답은 간단합니다. 예, 더 나아가 실제적인 문제를 해결해야 했고 이 툴라로 해결했습니다.

길은 항상 이렇습니다. 우리는 매우 신중하게 검색하고 빵 한 덩어리로 무궤도 전차를 만드는 방법에 대한 해결책을 찾지 못하면 우리 자신의 빵과 무궤도 전차를 만듭니다.

플란타 도구

— Flant에는 이제 애드온 연산자, 쉘 연산자 및 dapp/werf 도구가 있다는 것을 알고 있습니다. 내가 이해하는 바에 따르면 이것은 다른 화신의 동일한 도구입니다. 또한 Flaunt에는 더 많은 다양한 도구가 있다는 것도 알고 있습니다. 이것이 사실입니까?

드미트리: GitHub에는 더 많은 정보가 있습니다. 지금 기억나는 바로는 모두가 좋아하는 Grafana 패널인 상태 맵이 있습니다. 이는 Medium의 Kubernetes 모니터링에 관한 거의 모든 두 번째 기사에서 언급됩니다. 상태 맵이 무엇인지 간략하게 설명하는 것은 불가능합니다. 별도의 문서가 필요하지만 Kubernetes에서는 시간 경과에 따른 상태를 표시해야 하는 경우가 많기 때문에 시간 경과에 따른 상태를 모니터링하는 데 매우 유용합니다. LogHouse도 있습니다. 이는 Kubernetes에서 로그를 수집하기 위한 ClickHouse와 흑마술을 기반으로 한 것입니다.

많은 유틸리티! 올해에는 수많은 내부 솔루션이 출시될 예정이므로 더 많은 솔루션이 출시될 예정입니다. 애드온 운영자를 기반으로 하는 매우 큰 애드온 중에는 Kubernetes용 애드온이 많이 있습니다. sert 관리자를 올바르게 설치하는 방법(인증서 관리 도구), 여러 액세서리와 함께 Prometheus를 올바르게 설치하는 방법 등 약 XNUMX가지가 있습니다. 데이터를 내보내고 무언가를 수집하는 바이너리인 Prometheus에는 가장 놀라운 그래픽과 경고가 있습니다. 이 모든 것은 클러스터에 설치되는 Kubernetes의 추가 기능 모음일 뿐이며 단순한 것에서 멋지고 정교한 자동으로 바뀌며 많은 문제가 이미 해결되었습니다. 네, 우리는 많은 일을 합니다.

생태계 개발

"내 생각에는 이것이 이 기기와 그 사용 방법의 개발에 매우 ​​큰 기여를 한 것 같습니다." 생태계 발전에 동일한 기여를 할 다른 사람이 누구인지 대략적으로 추정할 수 있습니까?

드미트리: 러시아에서는 우리 시장에서 활동하는 회사 중 누구도 가까이 있지 않습니다.. 물론 이것은 큰 소리입니다. Mail 및 Yandex와 같은 주요 기업이 있기 때문입니다. 그들도 Kubernetes를 사용하여 무언가를 하고 있지만 심지어 우리보다 훨씬 더 많은 일을 하는 전 세계 기업의 기여에 근접하지 못합니다. 직원이 80명인 플란트(Flant)와 쿠버네티스당 엔지니어가 300명인 레드햇(Red Hat)을 비교하는 것은 틀리지 않으면 어렵다. 비교하기가 어렵습니다. RnD 부서에는 저를 포함해 모든 도구를 절단하는 사람이 6명 있습니다. 6명 대 300명의 Red Hat 엔지니어 - 비교하기가 좀 어렵습니다.

- 하지만 이 6명조차도 정말 유용하고 소외되는 일을 할 수 있을 때, 현실적인 문제에 직면하여 커뮤니티에 해결책을 제시할 때 - 흥미로운 사례입니다. 자체 Kubernetes 개발 및 지원 팀이 있는 대규모 기술 회사에서는 원칙적으로 동일한 도구를 개발할 수 있다는 것을 이해합니다. 이는 Kubernetes를 사용하는 전체 커뮤니티에 자극을 주면서 개발하여 커뮤니티에 제공할 수 있는 예입니다.

드미트리: 이것은 아마도 적분기의 특징, 특이성일 것입니다. 우리는 많은 프로젝트를 갖고 있으며 다양한 상황을 봅니다. 우리에게 부가가치를 창출하는 주요 방법은 이러한 사례를 분석하고 공통점을 찾아 가능한 한 저렴하게 만드는 것입니다. 우리는 이에 대해 적극적으로 노력하고 있습니다. 러시아와 세계에 대해 이야기하기는 어렵지만 회사에는 Kubernetes 작업을 수행하는 DevOps 엔지니어가 약 40명 있습니다. 러시아에는 쿠버네티스를 이해하는 전문가가 비슷한 수로 많은 회사가 없다고 생각합니다.

나는 DevOps 엔지니어라는 직위에 대한 모든 것을 이해하고 있으며 모두가 모든 것을 이해하고 DevOps 엔지니어 DevOps 엔지니어에게 전화하는 데 익숙합니다. 이에 대해서는 논의하지 않겠습니다. 이 40명의 놀라운 DevOps 엔지니어는 모두 매일 문제에 직면하고 해결합니다. 우리는 이 경험을 분석하고 일반화하려고 노력합니다. 우리는 그것이 우리 안에 남아 있으면 XNUMX~XNUMX년 안에 도구가 쓸모 없게 될 것임을 이해합니다. 왜냐하면 커뮤니티 어딘가에 기성품 툴라가 나타날 것이기 때문입니다. 이 경험을 내부적으로 축적하는 것은 의미가 없습니다. 이는 단지 dev/null에 에너지와 시간을 낭비하는 것뿐입니다. 그리고 우리는 그것에 대해 전혀 미안함을 느끼지 않습니다. 우리는 모든 것을 큰 기쁨으로 출판하고 사람들이 그것을 사용하고 경험을 추가할 수 있도록 출판, 개발, 홍보, 홍보가 필요하다는 것을 이해합니다. 그러면 모든 것이 성장하고 살아납니다. 그러면 XNUMX년이 지나면 그 악기는 쓰레기통에 버리지 않습니다. 누군가가 당신의 도구를 사용하고 있다는 것이 분명하고, XNUMX년이 지나면 모두가 그것을 사용하게 되기 때문에 계속해서 힘을 쏟는 것은 안타까운 일이 아닙니다.

이것은 dapp/werf를 통한 우리의 큰 전략의 일부입니다.. 언제부터 만들기 시작했는지는 기억나지 않는데, 3년쯤 전인 것 같습니다. 처음에는 일반적으로 쉘에 있었습니다. 그것은 매우 뛰어난 개념 증명이었고 우리는 특정 문제 중 일부를 해결했습니다. 효과가 있었습니다! 그러나 셸에는 문제가 있으며 더 이상 확장할 수 없으며 셸에서 프로그래밍하는 것은 또 다른 작업입니다. 우리는 Ruby로 글을 쓰는 습관이 있어서 Ruby로 뭔가를 리메이크하고, 개발하고, 개발하고, 개발하고, 커뮤니티, "우리가 원한다, 원하지 않는다"라고 말하지 않는 군중, "라고 Ruby에게 코를 치켜세우는데, 그게 얼마나 웃기나요? 우리는 체크리스트의 첫 번째 항목을 충족하기 위해 이 모든 항목을 Go로 작성해야 한다는 것을 깨달았습니다. DevOps 도구는 정적 바이너리여야 합니다.. Go가 될지 말지는 그다지 중요하지 않지만 Go로 작성된 정적 바이너리가 더 좋습니다.

우리는 에너지를 소비하고 Go에서 dapp을 다시 작성하여 werf라고 불렀습니다. 일부 최신 버전에서는 Dapp이 더 이상 지원되지 않고, 개발되지 않고, 실행되고 있지만, 맨 위로 올라가는 절대적인 업그레이드 경로가 있으며 이를 따라갈 수 있습니다.

Dapp은 왜 만들어졌나요?

— Dapp이 왜 만들어졌는지, 어떤 문제를 해결하는지 간략하게 알려주실 수 있나요?

드미트리: 첫 번째 이유는 집회에 있습니다. 처음에는 Docker에 다단계 기능이 없을 때 빌드에 심각한 문제가 있었기 때문에 자체적으로 다단계를 만들었습니다. 그런 다음 이미지를 정리하는 데 더 많은 문제가 발생했습니다. CI/CD를 하는 모든 사람들은 수집된 이미지가 너무 많아서 어떻게든 필요하지 않은 것을 정리하고 필요한 것은 남겨두어야 한다는 문제에 직면하게 됩니다.

두 번째 이유는 배포입니다. 예, Helm이 있지만 일부 문제만 해결합니다. 재미있게도 "Helm은 Kubernetes용 패키지 관리자입니다."라고 적혀 있습니다. 정확히 "the"가 무엇인지. "패키지 관리자"라는 단어도 있습니다. 패키지 관리자에게 일반적으로 기대하는 바는 무엇입니까? "패키지 관리자 - 패키지를 설치하세요!"라고 말합니다. 그리고 우리는 그가 우리에게 “패키지가 배달되었습니다.”라고 말할 것이라고 기대합니다.

흥미로운 점은 우리가 "Helm, 패키지를 설치하세요"라고 말하고 그가 패키지를 설치했다고 대답했을 때 그가 방금 설치를 시작했다는 사실입니다. 그는 Kubernetes에 "이 것을 실행해 보세요!"라고 표시했으며 시작 여부도 확인했습니다. , 작동 여부에 관계없이 Helm은 이 문제를 전혀 해결하지 않습니다.

Helm은 Kubernetes에 데이터를 로드하는 텍스트 전처리기일 뿐이라는 것이 밝혀졌습니다.

하지만 배포의 일부로 애플리케이션이 프로덕션용으로 출시되었는지 여부를 알고 싶습니다. 프로덕션으로 롤아웃된다는 것은 애플리케이션이 그곳으로 이동했고, 새 버전이 배포되었으며, 적어도 거기에서 충돌이 발생하지 않고 올바르게 응답한다는 것을 의미합니다. Helm은 어떤 방식으로도 이 문제를 해결하지 않습니다. 이 문제를 해결하려면 많은 노력을 기울여야 합니다. Kubernetes에 배포 또는 롤아웃 여부에 관계없이 거기서 일어나는 일을 롤아웃하고 모니터링하는 명령을 제공해야 하기 때문입니다. 그리고 전개, 청소, 조립과 관련된 업무도 많습니다.

계획

올해부터 지역개발을 시작하겠습니다. 우리는 이전에 Vagrant에서 있었던 것을 달성하고 싶습니다. "vagrant up"을 입력하고 가상 머신을 배포했습니다. 우리는 Git에 프로젝트가 있는 지점에 도달하고 싶습니다. 거기에 “werf up”을 쓰면 개발에 편리한 모든 디렉터리가 연결된 로컬 미니 Kub에 배포된 이 프로젝트의 로컬 복사본이 나타납니다. . 개발 언어에 따라 다르게 진행되지만, 그럼에도 불구하고 마운트된 파일 하에서 로컬 개발을 편리하게 수행할 수 있습니다.

우리의 다음 단계는 개발자의 편의성에 투자하다. 하나의 도구를 사용하여 프로젝트를 로컬로 빠르게 배포하려면 프로젝트를 개발하고 Git으로 푸시하세요. 또한 파이프라인에 따라 단계나 테스트로 롤아웃된 다음 동일한 도구를 사용하여 프로덕션으로 이동합니다. 지역 환경부터 판매까지 인프라의 통일성, 통일성, 재현성은 우리에게 매우 중요한 포인트입니다. 그러나 이것은 아직 werf에 포함되지 않았습니다. 우리는 단지 그것을 할 계획입니다.

하지만 dapp/werf로 가는 길은 항상 처음의 Kubernetes와 동일했습니다. 우리는 문제에 직면했고, 해결 방법으로 이를 해결했습니다. 우리는 쉘에서 무엇이든 스스로 몇 가지 솔루션을 생각해 냈습니다. 그런 다음 그들은 이러한 해결 방법을 어떻게든 정리하고, 일반화하고, 이 경우 바이너리로 통합하려고 시도했으며, 우리는 이를 간단히 공유합니다.

비유를 통해 이 전체 이야기를 보는 또 다른 방법이 있습니다.

쿠버네티스는 엔진이 달린 자동차 프레임이다. 문, 유리, 라디오, 크리스마스 트리 등 전혀 없습니다. 프레임과 엔진만 있으면 됩니다. 그리고 Helm이 있습니다. 이것은 스티어링 휠입니다. 멋지네요. 스티어링 휠이 있지만 스티어링 핀, 스티어링 랙, 기어박스 및 휠도 필요하며, 스티어링 휠 없이는 할 수 없습니다.

Werf의 경우 이는 Kubernetes의 또 다른 구성 요소입니다. 예를 들어, 지금은 werf의 알파 버전에서만 Helm이 werf 내부에서 컴파일됩니다. 왜냐하면 우리가 직접 수행하는 데 지쳤기 때문입니다. 이렇게 하는 데에는 여러 가지 이유가 있습니다. 우리가 werf 내부의 경운기와 함께 전체 조타 장치를 컴파일한 이유에 대해 자세히 설명하겠습니다. RIT++ 보고서에서.

이제 werf는 더욱 통합된 구성 요소입니다. 우리는 완성된 스티어링 휠과 스티어링 핀을 얻습니다. 저는 자동차에 능숙하지 않지만 이것은 이미 상당히 광범위한 문제를 해결하는 큰 블록입니다. 우리는 카탈로그를 직접 살펴보고, 한 부품을 다른 부품으로 선택하고, 부품을 어떻게 결합할지 생각할 필요가 없습니다. 우리는 한 번에 많은 문제를 해결하는 기성품 결합을 얻습니다. 그러나 내부는 동일한 오픈 소스 구성 요소로 구축되었으며 여전히 조립을 위해 Docker를 사용하고 일부 기능을 위해 Helm을 사용하며 기타 여러 라이브러리가 있습니다. 이것은 멋진 CI/CD를 빠르고 편리하게 사용할 수 있는 통합 도구입니다.

Kubernetes는 유지 관리가 어렵나요?

— Kubernetes를 사용하기 시작한 경험에 대해 이야기합니다. 이것은 당신을 위한 프레임인 엔진이며 그 위에 몸체, 스티어링 휠, 나사식 페달, 시트 등 다양한 것들을 걸 수 있다고 말했습니다. 질문이 생깁니다. Kubernetes 지원이 얼마나 어려운가요? 당신은 많은 경험을 가지고 있습니다. 다른 모든 것으로부터 격리되어 Kubernetes를 지원하는 데 얼마나 많은 시간과 리소스를 소비합니까?

드미트리: 이것은 매우 어려운 질문이며 대답하려면 지원이 무엇인지, Kubernetes에서 원하는 것이 무엇인지 이해해야 합니다. 어쩌면 공개할 수 있을까요?

— 제가 아는 한, 제가 본 바로는 현재 많은 팀이 Kubernetes를 사용해 보고 싶어합니다. 모두가 그것을 활용하고 무릎을 꿇습니다. 나는 사람들이 이 시스템의 복잡성을 항상 이해하지 못한다는 느낌을 받았습니다.

드미트리: 그렇군요.

— 프로덕션 준비가 완료되도록 Kubernetes를 처음부터 가져와 설치하는 것이 얼마나 어렵나요?

드미트리: 심장이식은 얼마나 어렵다고 생각하시나요? 나는 이것이 타협적인 질문이라는 것을 이해합니다. 메스를 사용하고 실수하지 않는 것은 그리 어렵지 않습니다. 자르는 위치와 바느질할 위치를 알려준다면 절차 자체는 복잡하지 않습니다. 모든 일이 잘 될 것이라고 시간이 지나도 보장하기는 어렵습니다.

Kubernetes를 설치하고 작동시키는 것은 쉽습니다. 병아리! — 설치, 설치 방법이 많이 있습니다. 하지만 문제가 발생하면 어떻게 되나요?

항상 질문이 발생합니다. 아직 고려하지 않은 것은 무엇입니까? 우리는 아직 무엇을 하지 않았나요? 어떤 Linux 커널 매개변수가 잘못 지정되었습니까? 맙소사, 우리가 그들에 대해 언급이라도 했었나요?! 우리가 제공한 Kubernetes 구성 요소는 무엇이며, 제공하지 않은 구성 요소는 무엇입니까? 수천 가지 질문이 발생하며 이에 답하려면 이 업계에서 15~20년을 보내야 합니다.

나는 이 주제에 대해 "Kubernetes를 유지 관리하기 어려운가?"라는 문제의 의미를 드러낼 수 있는 최근 사례를 가지고 있습니다. 얼마 전 우리는 Cilium을 Kubernetes의 네트워크로 구현해야 할지 진지하게 고려했습니다.

Cilium이 무엇인지 설명하겠습니다. Kubernetes에는 네트워킹 하위 시스템에 대한 다양한 구현이 있으며 그 중 하나가 매우 훌륭합니다 - Cilium. 그 의미는 무엇입니까? 커널에서는 얼마 전에 커널에 대한 후크를 작성하는 것이 가능해졌습니다. 이 후크는 어떤 방식으로든 네트워크 하위 시스템과 다양한 기타 하위 시스템을 침범하고 커널의 큰 덩어리를 우회할 수 있게 해줍니다.

Linux 커널에는 역사적으로 IP 라우팅, 오버필터, 브리지 및 15, 20, 30년 된 다양한 오래된 구성 요소가 있습니다. 일반적으로 그들은 작동하고 모든 것이 훌륭하지만 이제는 컨테이너가 쌓여 있고 15 개의 벽돌이 서로 겹쳐진 탑처럼 보이며 한쪽 다리로 서 있습니다. 이상한 느낌입니다. 이 시스템은 역사적으로 신체의 맹장처럼 여러 가지 미묘한 차이로 발전해 왔습니다. 예를 들어 어떤 상황에서는 성능 문제가 있습니다.

훌륭한 BPF와 커널용 후크를 작성하는 기능이 있습니다. 사람들은 커널용 후크를 직접 작성했습니다. 패키지는 Linux 커널에 들어와서 입력에서 바로 꺼내어 브리지 없이, TCP 없이, IP 스택 없이 필요한 대로 자체적으로 처리합니다. 즉, Linux 커널에 작성된 모든 것을 우회한 다음 침을 뱉습니다. 그것을 용기에 담습니다.

무슨 일이에요? 매우 멋진 성능, 멋진 기능 - 정말 멋집니다! 그러나 우리는 이를 살펴보고 각 시스템에는 Kubernetes API에 연결하고 이 API에서 수신한 데이터를 기반으로 C 코드를 생성하고 이러한 후크가 작동하도록 커널에 로드되는 바이너리를 컴파일하는 프로그램이 있음을 확인합니다. 커널 공간에서.

문제가 발생하면 어떻게 되나요? 우리는 모른다. 이것을 이해하려면 이 코드를 모두 읽고, 모든 로직을 이해해야 하는데, 그게 얼마나 어려운지 놀라울 정도입니다. 하지만 다른 한편으로는 이러한 브리지, 넷 필터, IP 라우터가 있습니다. 저는 그 소스 코드를 읽지 않았고 우리 회사에서 일하는 40명의 엔지니어도 읽지 않았습니다. 어쩌면 소수만이 일부 부분을 이해하고 있을지도 모릅니다.

그리고 차이점은 무엇입니까? ip rout, Linux 커널이 있고 새로운 도구가 있다는 것이 밝혀졌습니다. 그것이 어떤 차이점을 가져오는지, 우리는 둘 중 하나를 이해하지 못합니다. 하지만 우리는 새로운 것을 사용하는 것을 두려워합니다. 왜일까요? 도구가 30년이 되면 30년 안에 모든 버그가 발견되고 모든 실수가 해결되었으며 모든 것에 대해 알 필요가 없기 때문입니다. 이는 블랙박스처럼 작동하며 항상 작동합니다. 어떤 진단 드라이버를 어느 위치에 꽂아야 할지, 어떤 순간에 어떤 tcpdump를 실행할지 모두가 알고 있습니다. 모든 사람은 진단 유틸리티를 잘 알고 있으며 이러한 구성 요소 세트가 Linux 커널에서 작동하는 방식(작동 방식이 아니라 사용 방법)을 이해합니다.

그리고 엄청나게 멋진 실리움은 30살도 아니고, 아직 늙지도 않았습니다. Kubernetes에도 동일한 문제가 있습니다. Cilium이 완벽하게 설치됐다는 것, Kubernetes가 완벽하게 설치됐다는 것, 프로덕션에서 문제가 발생했을 때, 무엇이 잘못됐는지 중요한 상황에서 빠르게 이해할 수 있습니까?

Kubernetes를 유지 관리하는 것이 어렵다고 말하면 아니요, 매우 쉽고, 그렇습니다. 엄청나게 어렵습니다. Kubernetes는 그 자체로 훌륭하게 작동하지만 수십억 가지의 미묘한 차이가 있습니다.

"나는 운이 좋을 것이다" 접근 방식에 대하여

— 이런 뉘앙스가 거의 확실하게 나타나는 기업이 있나요? Yandex가 갑자기 모든 서비스를 Kubernetes로 이전한다고 가정하면 거기에 엄청난 부하가 발생하게 됩니다.

드미트리: 아니요, 이것은 부하에 대한 대화가 아니라 가장 간단한 것에 대한 대화입니다. 예를 들어 Kubernetes가 있고 거기에 애플리케이션을 배포했습니다. 작동하는지 어떻게 알 수 있나요? 애플리케이션이 충돌하지 않는다는 것을 이해할 수 있는 기성 도구가 없습니다. 경고를 보내는 기성 시스템이 없으므로 이러한 경고와 각 일정을 구성해야 합니다. 그리고 우리는 Kubernetes를 업데이트하고 있습니다.

우분투 16.04가 있습니다. 이것이 오래된 버전이라고 말할 수 있지만 LTS이기 때문에 우리는 여전히 버전을 유지하고 있습니다. systemd가 있는데 그 뉘앙스는 C 그룹을 정리하지 않는다는 것입니다. Kubernetes는 포드를 시작하고, C 그룹을 생성한 다음 포드를 삭제하지만 어떻게든 세부 사항은 기억나지 않습니다. 죄송합니다. systemd 슬라이스가 남아 있다는 사실이 밝혀졌습니다. 이는 시간이 지남에 따라 모든 자동차가 강하게 속도를 늦추기 시작한다는 사실로 이어집니다. 이것은 하이로드에 관한 질문조차 아닙니다. 예를 들어 영구 포드가 시작되면 지속적으로 포드를 생성하는 Cron 작업이 있는 경우 Ubuntu 16.04가 설치된 시스템은 일주일 후에 속도가 느려지기 시작합니다. 다수의 C 그룹이 생성되었기 때문에 지속적으로 높은 로드 평균이 발생합니다. 이는 단순히 Ubuntu 16과 Kubernetes를 위에 설치하는 사람이라면 누구나 직면하게 되는 문제입니다.

그가 어떻게든 systemd나 다른 것을 업데이트한다고 가정해 보겠습니다. 그러나 Linux 커널 최대 4.16에서는 더욱 재미있습니다. C 그룹을 삭제하면 커널에서 누출되고 실제로 삭제되지 않습니다. 따라서 이 기계에서 한 달 동안 작업한 후에는 난로에 대한 메모리 통계를 보는 것이 불가능합니다. 파일을 꺼내 프로그램에 넣고 파일 하나를 15초 동안 굴립니다. 커널이 자체 내에서 백만 개의 C 그룹을 계산하는 데 매우 오랜 시간이 걸리기 때문에 삭제된 것처럼 보이지만 그렇지 않습니다. 누출되고 있습니다. .

아직도 이런 자잘한 것들이 여기저기 많이 남아있습니다. 이는 거대 기업이 때때로 매우 무거운 업무에 직면할 수 있는 문제가 아니라, 일상적인 문제입니다. 사람들은 몇 달 동안 이렇게 살 수 있습니다. Kubernetes를 설치하고 애플리케이션을 배포했습니다. 작동하는 것 같습니다. 많은 사람들에게 이는 정상적인 현상입니다. 그들은 어떤 이유로든 이 응용 프로그램이 충돌할 것이라는 사실조차 모르고 경고를 받지도 못하지만, 그들에게는 이것이 표준입니다. 이전에는 모니터링 없이 가상 머신에서 살았지만 이제는 모니터링 없이 Kubernetes로 전환했습니다. 차이점은 무엇입니까?

문제는 우리가 얼음 위를 걸을 때 미리 측정하지 않으면 그 두께를 결코 알 수 없다는 것입니다. 많은 사람들이 걷고 있지만 걱정하지 않습니다. 왜냐하면 그들은 이전에 걸어본 적이 있기 때문입니다.

내 관점에서는 모든 시스템 운영의 뉘앙스와 복잡성은 얼음의 두께가 문제를 해결하기에 충분하도록 보장하는 것입니다. 이것이 우리가 말하는 것입니다.

IT 분야에는 "나는 운이 좋을 것이다"라는 접근 방식이 너무 많은 것 같습니다. 많은 사람들이 행운을 바라며 소프트웨어를 설치하고 소프트웨어 라이브러리를 사용합니다. 일반적으로 많은 사람들이 운이 좋습니다. 아마도 그것이 작동하는 이유 일 것입니다.

— 내 비관적인 평가에 따르면 다음과 같습니다. 위험이 높고 애플리케이션이 작동해야 하는 경우 Flaunt(아마도 Red Hat)의 지원이 필요하거나 준비된 Kubernetes 전용 내부 팀이 필요합니다. 그것을 떼어 내기 위해.

드미트리: 객관적으로는 그렇습니다. 소규모 팀을 위한 Kubernetes 스토리에 혼자서 참여하려면 여러 가지 위험이 따릅니다.

컨테이너가 필요한가요?

— 러시아에서 Kubernetes가 얼마나 널리 퍼져 있는지 알려주실 수 있나요?

드미트리: 이 데이터는 나에게 없고 다른 사람이 가지고 있는지도 확실하지 않습니다. 우리는 "Kubernetes, Kubernetes"라고 말하지만 이 문제를 보는 또 다른 방법이 있습니다. 또한 컨테이너가 얼마나 널리 퍼져 있는지는 모르지만 컨테이너의 70%가 Kubernetes에 의해 조정된다는 인터넷 보고서의 수치는 알고 있습니다. 전 세계적으로 상당히 큰 샘플을 얻을 수 있는 신뢰할 수 있는 소스였습니다.

그러면 또 다른 질문이 있습니다. 컨테이너가 필요한가요? 내 개인적 느낌과 Flant 회사의 전반적인 입장은 Kubernetes가 사실상의 표준이라는 것입니다.

Kubernetes 외에는 아무것도 없을 것입니다.

이는 인프라 관리 분야의 획기적인 변화입니다. 단지 절대적입니다. 더 이상 Ansible, Chef, 가상 머신, Terraform이 없습니다. 나는 오래된 집단 농장 방법에 대해 말하는 것이 아닙니다. Kubernetes는 절대적인 변화입니다, 이제는 이렇습니다.

이것을 깨닫는 데 어떤 사람은 XNUMX년이 걸리고 어떤 사람은 XNUMX년이 걸린다는 것은 분명합니다. 저는 Kubernetes와 이 새로운 모습 외에는 아무것도 없을 것이라고 의심하지 않습니다. 우리는 더 이상 운영 체제를 손상시키지 않고 코드로서의 인프라, 코드가 아닌 선언적으로 설명된 인프라인 yml을 사용합니다. 앞으로도 계속 이럴 것 같은 느낌이 듭니다.

— 즉, 아직 Kubernetes로 전환하지 않은 회사는 반드시 Kubernetes로 전환하거나 망각 상태로 남을 것입니다. 내가 이해한 게 맞나요?

드미트리: 이 역시 전적으로 사실은 아닙니다. 예를 들어, DNS 서버를 실행하는 작업이 있다면 FreeBSD 4.10에서 실행될 수 있으며 20년 동안 완벽하게 작동할 수 있습니다. 그냥 일하면 끝입니다. 아마도 20년 후에는 뭔가를 한 번 업데이트해야 할 것입니다. 우리가 출시한 형식의 소프트웨어에 대해 이야기하고 있고 실제로 업데이트나 변경 없이 수년 동안 작동한다면 물론 Kubernetes는 없을 것입니다. 그는 거기에 필요하지 않습니다.

CI/CD와 관련된 모든 것 - 지속적인 전달이 필요한 곳, 버전을 업데이트해야 하는 곳, 적극적으로 변경해야 하는 곳, 내결함성을 구축해야 하는 곳 모두 - 오직 Kubernetes입니다.

마이크로서비스 정보

- 여기에 약간의 불협화음이 있습니다. Kubernetes를 사용하려면 외부 또는 내부 지원이 필요합니다. 이것이 첫 번째 사항입니다. 둘째, 이제 막 개발을 시작하는 단계에서는 소규모 스타트업이고 아직 아무것도 갖고 있지 않습니다. 일반적으로 Kubernetes 또는 마이크로서비스 아키텍처 개발은 복잡할 수 있으며 항상 경제적으로 정당화되지는 않습니다. 귀하의 의견에 관심이 있습니다. 스타트업은 즉시 처음부터 Kubernetes용 작성을 시작해야 합니까, 아니면 여전히 모놀리스를 작성하고 Kubernetes로만 올 수 있습니까?

드미트리: 멋진 질문입니다. 마이크로서비스에 대해 이야기하겠습니다. "마이크로서비스: 크기가 중요합니다." 나는 현미경으로 못을 망치려고 하는 사람들을 여러 번 만났습니다. 접근 방식 자체는 정확합니다. 우리는 내부 소프트웨어를 이런 식으로 설계합니다. 하지만 이렇게 할 때는 자신이 하고 있는 일을 명확하게 이해해야 합니다. 제가 마이크로서비스에 대해 가장 싫어하는 단어는 "마이크로"입니다. 역사적으로 이 단어는 그곳에서 유래되었으며 어떤 이유로 사람들은 마이크로가 마이크로미터처럼 밀리미터 미만으로 매우 작다고 생각합니다. 이것은 잘못된 것입니다.

예를 들어, 300명이 작성한 모놀리스가 있는데 개발에 참여한 모든 사람은 거기에 문제가 있다는 것을 이해하고 이를 작은 조각으로 나누어야 합니다. 각 조각은 10명이 작성했습니다. 최소 버전으로. 이것은 중요하고 필요하며 멋지다. 그러나 매우 멋지고 재능 있는 세 명의 남자가 무릎을 꿇고 30개의 마이크로서비스를 작성한 스타트업이 우리에게 오면 Corvalol을 찾을 때마다 그렇습니다.

이것은 이미 수천 번 이야기된 것 같습니다. 우리는 어떤 형태로든 분산된 단일체를 얻었습니다. 이것은 경제적으로 타당하지 않으며 일반적으로 모든면에서 매우 어렵습니다. 너무 많이 봐서 너무 마음이 아팠기 때문에 계속해서 얘기를 하게 됐어요.

초기 질문에 대해 Kubernetes는 사용하기가 두렵다는 사실 사이에 충돌이 있습니다. 왜냐하면 무엇이 거기에서 깨질 수 있는지 또는 작동하지 않을지 명확하지 않기 때문입니다. 다른 한편으로는 모든 것이 거기에 있다는 것이 분명합니다. Kubernetes 외에는 아무것도 존재하지 않을 것입니다. 답변 - 얻을 수 있는 혜택의 양, 해결할 수 있는 작업의 양을 평가해 보세요.. 이것은 저울의 한쪽에 있습니다. 반면에 가동 중지 시간이나 응답 시간 감소, 가용성 수준 감소, 성능 지표 감소와 관련된 위험이 있습니다.

여기 있습니다. 빠르게 움직이면 Kubernetes를 통해 많은 일을 훨씬 빠르고 효율적으로 수행할 수 있습니다. 아니면 안정적이고 오랜 테스트를 거친 솔루션을 사용하지만 훨씬 느리게 움직입니다. 이는 모든 기업이 해야 할 선택입니다. 정글 속의 길이라고 생각하시면 됩니다. 처음 걸으면 뱀이나 호랑이, 미친 오소리를 만날 수 있고, 10번 걸으면 그 길을 밟고 걷게 됩니다. 가지와 걷기가 더 쉬워졌습니다. 매번 경로가 넓어집니다. 그 다음은 아스팔트 도로이고 나중에는 아름다운 대로가 됩니다.

Kubernetes는 가만히 있지 않습니다. 다시 질문하세요. Kubernetes는 한편으로는 4~5개의 바이너리이고 다른 한편으로는 전체 생태계입니다. 이것이 우리 컴퓨터에 있는 운영 체제입니다. 이게 뭔가요? 우분투나 큐리오스? 이것은 추가 구성 요소 묶음인 Linux 커널입니다. 이 모든 것, 독사 한 마리가 길에서 쫓겨나고 거기에 울타리가 세워졌습니다. Kubernetes는 매우 빠르고 동적으로 발전하고 있으며 위험의 양, 미지의 양이 매달 감소하고 있으며 이에 따라 이러한 규모가 재조정되고 있습니다.

스타트업이 무엇을 해야 하는지에 대한 질문에 대답하고 싶습니다. Flaunt에 와서 150만 루블을 지불하고 턴키 DevOps 쉬운 서비스를 받으십시오. 개발자가 몇 명 있는 소규모 스타트업이라면 이 방법이 효과적입니다. 현재 문제를 해결하고 급여를 지불하는 방법을 배워야 하는 자체 DevOps를 고용하는 대신 모든 문제에 대한 턴키 솔루션을 얻을 수 있습니다. 예, 몇 가지 단점이 있습니다. 아웃소싱업체인 우리는 변화에 너무 관여하고 신속하게 대응할 수 없습니다. 그러나 우리는 많은 전문 지식과 기성 관행을 보유하고 있습니다. 우리는 어떤 상황에서도 신속하게 문제를 파악하고 모든 Kubernetes를 죽음에서 부활시킬 것이라고 보장합니다.

저는 10명으로 구성된 팀을 운영에 전념할 수 있는 규모까지 스타트업 및 기존 기업에 아웃소싱하는 것을 강력히 권장합니다. 그렇지 않으면 아무런 의미가 없기 때문입니다. 이것을 아웃소싱하는 것이 확실히 합리적입니다.

아마존과 구글에 대하여

— Amazon이나 Google 솔루션의 호스트를 아웃소싱으로 간주할 수 있나요?

드미트리: 네, 물론이죠. 이렇게 하면 여러 가지 문제가 해결됩니다. 그러나 다시 뉘앙스가 있습니다. 여전히 그것을 사용하는 방법을 이해해야 합니다. 예를 들어, Amazon AWS 작업에는 수천 가지 작은 작업이 있습니다. 로드 밸런서를 워밍업해야 하거나 "얘들아, 우리가 트래픽을 받을 테니 로드 밸런서를 워밍업해 주세요!"라는 요청을 미리 작성해야 합니다. 이러한 뉘앙스를 알아야합니다.

이 분야를 전문으로 하는 사람들에게 문의하면 거의 모든 일반적인 문제가 해결됩니다. 우리는 현재 40명의 엔지니어를 보유하고 있으며, 올해 말에는 아마도 60명으로 늘어날 것입니다. 우리는 확실히 이 모든 것을 경험했습니다. 어떤 프로젝트에서 이런 문제가 다시 발생하더라도 우리는 서로 빠르게 물어보고 해결 방법을 알고 있습니다.

아마도 대답은 '물론 호스팅된 스토리가 어떤 부분을 더 쉽게 만들어준다'일 것입니다. 문제는 귀하가 이러한 호스팅 업체를 신뢰할 준비가 되었는지, 그리고 이들이 귀하의 문제를 해결할 것인지 여부입니다. 아마존과 구글은 잘 해냈다. 우리의 모든 경우에 - 정확합니다. 더 이상 긍정적인 경험은 없습니다. 우리가 작업하려고 시도한 다른 모든 클라우드는 Ager, 러시아에 있는 모든 것, Headster, Overage 등 원하는 대로 다양한 구현의 모든 종류의 OpenStack 등 많은 문제를 야기했습니다. 그들은 모두 당신이 해결하고 싶지 않은 문제를 만듭니다.

따라서 대답은 '예'입니다. 하지만 실제로 성숙한 호스팅 솔루션은 그리 많지 않습니다.

Kubernetes가 필요한 사람은 누구입니까?

— 그런데 누가 Kubernetes를 필요로 할까요? 누가 이미 Kubernetes로 전환해야 합니까? Kubernetes를 위해 특별히 제공되는 일반적인 Flaunt 클라이언트는 누구입니까?

드미트리: 이것은 흥미로운 질문입니다. 왜냐하면 지금 Kubernetes의 여파로 많은 사람들이 우리에게 오기 때문입니다. "얘들아, 우리는 당신들이 Kubernetes를 하고 있다는 것을 알고 있습니다. 우리를 위해 그것을 해주세요!" 우리는 그들에게 이렇게 대답합니다. "여러분, 우리는 Kubernetes를 하는 것이 아니라 prod 및 이와 관련된 모든 것을 합니다." 현재로서는 CI/CD와 전체적인 스토리를 모두 하지 않고는 제품을 만드는 것이 불가능하기 때문입니다. 모두가 개발에 개발을, 착취에 착취를 한다는 구분에서 벗어났습니다.

우리 고객은 서로 다른 것을 기대하지만 모두가 특정 문제가 있다는 좋은 기적을 기다리고 있습니다. 이제 뛰어보세요! — Kubernetes가 이를 해결해 드립니다. 사람들은 기적을 믿습니다. 그들은 마음 속으로는 기적이 없을 것이라는 것을 이해하지만 영혼 속으로는 희망합니다. 이 Kubernetes가 이제 우리를 위해 모든 것을 해결해 준다면 어떨까요? 그들은 그것에 대해 너무 많이 이야기합니다! 갑자기 그는 지금 재채기를 해요! - 그리고 은색 총알, 재채기! — 그리고 우리는 100% 가동 시간을 갖고 있으며, 모든 개발자는 프로덕션에 들어가는 모든 것을 50번 릴리스할 수 있으며 충돌이 발생하지 않습니다. 일반적으로 기적입니다!

그런 사람들이 우리에게 오면 우리는 “죄송하지만 기적은 없습니다”라고 말합니다. 건강하려면 잘 먹고 운동해야 합니다. 믿을 수 있는 제품을 가지려면 믿을 수 있게 만들어져야 합니다. 편리한 CI/CD를 만들려면 이렇게 만들어야 합니다. 그것은 수행해야 할 많은 작업입니다.

Kubernetes가 필요한 사람이 누구인지에 대한 질문에 답하기 - Kubernetes가 필요한 사람은 없습니다.

어떤 사람들은 Kubernetes가 필요하다는 오해를 가지고 있습니다. 사람들은 인프라의 모든 문제와 애플리케이션 실행 문제에 대해 생각하고, 연구하고, 관심을 갖는 것을 멈추고 싶은 깊은 욕구를 가지고 있습니다. 그들은 애플리케이션이 제대로 작동하고 배포되기를 원합니다. 그들에게 쿠버네티스는 "우리는 거기 누워 있었다", "우리는 출시할 수 없다" 등의 이야기를 더 이상 듣지 않기를 바라는 희망입니다.

기술 이사는 대개 우리에게옵니다. 그들은 그에게 두 가지를 묻습니다. 한편으로는 기능을 제공하고 다른 한편으로는 안정성을 제공합니다. 우리는 당신이 스스로 그것을 받아들이고 그것을 하는 것을 제안합니다. 묘책, 아니 오히려 은도금은 이러한 문제에 대해 생각하지 않고 시간을 낭비하지 않게 된다는 것입니다. 이 문제를 마무리할 특별한 사람들이 있을 것입니다.

우리 또는 다른 누구에게나 Kubernetes가 필요하다는 표현은 올바르지 않습니다.

관리자에게는 Kubernetes가 꼭 필요합니다. 왜냐하면 Kubernetes는 가지고 놀고 만질 수 있는 매우 흥미로운 장난감이기 때문입니다. 솔직하게 말하자면, 모두가 장난감을 좋아합니다. 우리는 모두 어딘가의 어린이이고, 새로운 것을 보면 놀고 싶어합니다. 예를 들어 행정부에서는 이미 충분히 플레이했고 단순히 원하지 않을 정도로 피곤하기 때문에 일부 사람들에게는 이것이 낙담되었습니다. 그러나 이것은 누구에게도 완전히 손실되지 않습니다. 예를 들어, 시스템 관리 및 DevOps 분야의 장난감에 오랫동안 지쳤다면 여전히 장난감을 좋아하고 새 장난감을 구입합니다. 어떤 식으로든 모든 사람들은 여전히 ​​어떤 종류의 장난감을 원합니다.

생산을 가지고 놀 필요가 없습니다. 내가 절대 하지 말 것을 권장하는 것과 지금 내가 보는 것이 한꺼번에: "아, 새 장난감이구나!" — 그들은 그것을 사러 달려가서 "이제 학교에 가져가서 모든 친구들에게 보여주자."라고 말했습니다. 이러지 마세요. 사과드립니다. 제 아이들은 이제 막 성장하고 있습니다. 저는 끊임없이 아이들에게서 무언가를 보고, 그것을 제 자신에게서 알아차리고, 그것을 다른 사람들에게 일반화합니다.

최종 대답은 Kubernetes가 필요하지 않다는 것입니다. 당신은 문제를 해결해야합니다.

당신이 달성할 수 있는 것은 다음과 같습니다:

• 찌르는 소리가 떨어지지 않습니다.
• 그가 넘어지려고 해도 우리는 그것에 대해 미리 알고 거기에 무엇인가를 넣을 수 있습니다.
• 비즈니스에서 요구하는 속도에 맞춰 변경할 수 있고 편리하게 변경할 수 있어 아무런 문제도 발생하지 않습니다.

실제로 필요한 두 가지가 있습니다. 바로 신뢰성과 롤아웃의 역동성/유연성입니다. 현재 어떤 종류의 비즈니스에 관계없이 IT 프로젝트를 수행하고 있는 모든 사람은 세상을 편하게 하는 소프트이며 이를 이해하는 사람은 이러한 요구 사항을 해결해야 합니다. 올바른 접근 방식, 올바른 이해, 충분한 경험을 갖춘 Kubernetes를 사용하면 문제를 해결할 수 있습니다.

서버리스 정보

— 조금 더 미래를 내다보고 인프라 문제가 없는 문제를 해결하려고 하면 출시 속도와 애플리케이션 변경 속도에 따라 서버리스와 같은 새로운 솔루션이 등장합니다. 이 방향에 어떤 잠재력이 있다고 생각하시나요? 예를 들어 Kubernetes 및 유사한 솔루션에 대한 위험이 있다고 생각하시나요?

드미트리: 여기서 우리는 나는 앞을 내다보고 이렇게 될 것이라고 말하는 선견자가 아니라는 점을 다시 한 번 언급해야 합니다. 나도 똑같은 일을했지만. 나는 내 발을보고 거기에서 많은 문제를 봅니다. 예를 들어 컴퓨터에서 트랜지스터가 작동하는 방식입니다. 재미있지 않나요? CPU에서 몇 가지 버그가 발생했습니다.

서버리스를 매우 안정적이고 저렴하며 효율적이고 편리하게 만들어 모든 생태계 문제를 해결합니다. 여기서 저는 인류의 내결함성을 구축하려면 두 번째 행성이 ​​필요하다는 Elon Musk의 의견에 동의합니다. 그가 무슨 말을 하는지는 모르겠지만, 나는 아직 화성으로 날아갈 준비가 되지 않았으며 내일은 그런 일이 일어나지 않을 것이라는 점을 이해합니다.

서버리스를 사용하면 이것이 인류에 대한 내결함성과 같이 이념적으로 올바른 것임을 분명히 알 수 있습니다. 두 개의 행성을 갖는 것이 하나보다 낫습니다. 하지만 지금은 어떻게 해야 할까요? 집중해서 노력하면 하나의 원정대를 보내는 것도 문제가 되지 않습니다. 여러 차례 원정대를 보내고 그곳에 수천 명을 정착시키는 것도 현실적이라고 생각합니다. 하지만 인류의 절반이 그곳에 살 수 있도록 완전히 내결함성을 만드는 것은 지금은 고려되지 않고 불가능한 것 같습니다.

서버리스 일대일: 문제는 좋지만 2019년의 문제와는 거리가 멀습니다. 2030년이 가까워질 때까지 살아서 지켜봅시다. 나는 우리가 살 것이라는 데 의심의 여지가 없으며 분명히 살 것입니다 (자기 전에 반복). 하지만 이제는 다른 문제를 해결해야합니다. 마치 동화 속 조랑말 레인보우를 믿는 것과 같습니다. 예, 몇 퍼센트의 사례가 해결되어 완벽하게 해결되었지만 주관적으로 서버리스는 무지개입니다... 나에게는 이 주제가 너무 멀고 이해하기 어렵습니다. 아직 얘기할 준비가 안 됐어요. 2019년에는 서버리스로 단일 애플리케이션을 작성할 수 없습니다.

쿠버네티스는 어떻게 진화할 것인가

— 우리가 이 놀라운 먼 미래를 향해 나아가면서 Kubernetes와 그 주변의 생태계가 어떻게 발전할 것이라고 생각하시나요?

드미트리: 이 문제에 대해 많이 생각해 봤는데 명확한 답이 있어요. 첫 번째는 Stateful입니다. 결국 Stateless가 더 쉽습니다. Kubernetes는 처음에 이에 더 많은 투자를 했고, 모든 것이 그것으로 시작되었습니다. Stateless는 Kubernetes에서 거의 완벽하게 작동하므로 불평할 것이 없습니다. 여전히 많은 문제가 있거나 오히려 뉘앙스가 있습니다. 그곳의 모든 것은 이미 우리에게 훌륭하게 작용하고 있지만 그게 바로 우리입니다. 이것이 모든 사람에게 적용되려면 적어도 몇 년은 더 걸릴 것입니다. 이것은 계산된 지표가 아니라 머리에서 나오는 느낌입니다.

간단히 말해서, 모든 애플리케이션이 상태를 저장하고 상태 비저장 애플리케이션이 없기 때문에 Statefull은 매우 강력하게 발전해야 하며 앞으로도 그럴 것입니다. 이것은 환상입니다. 항상 일종의 데이터베이스와 다른 것이 필요합니다. Statefull은 가능한 모든 것을 정리하고, 모든 버그를 수정하고, 현재 직면하고 있는 모든 문제를 개선하는 것입니다. 이를 채택이라고 부르겠습니다.

미지의 수준, 해결되지 않은 문제의 수준, 무언가에 직면할 확률의 수준이 크게 떨어집니다. 이것은 중요한 이야기입니다. 그리고 운영자 - 쉬운 서비스를 얻기 위한 관리 논리, 제어 논리의 코드화와 관련된 모든 것: MySQL 쉬운 서비스, RabbitMQ 쉬운 서비스, Memcache 쉬운 서비스 - 일반적으로 우리가 작업을 보장해야 하는 이러한 모든 구성 요소 상자. 이는 데이터베이스를 원하지만 관리하고 싶지 않거나, Kubernetes를 원하지만 관리하고 싶지 않은 문제를 해결할 뿐입니다.

어떤 형태로든 운영자 개발에 대한 이 이야기는 향후 몇 년 동안 중요해질 것입니다.

나는 사용 편의성이 크게 높아져야 한다고 생각합니다. 상자는 점점 더 단순한 손잡이로 인해 점점 더 검어지고, 점점 더 안정적이 될 것입니다.

저는 Saturday Night Live에서 YouTube를 통해 80년대 Isaac Asimov와의 오래된 인터뷰를 들은 적이 있습니다. Urgant와 같은 프로그램이지만 흥미로울 뿐입니다. 그들은 그에게 컴퓨터의 미래에 대해 물었습니다. 그는 미래는 라디오처럼 단순함에 있다고 말했습니다. 라디오 수신기는 원래 복잡한 것이었습니다. 파도를 잡으려면 15분 동안 손잡이를 돌리고 꼬치를 돌려서 모든 것이 어떻게 작동하는지 일반적으로 알고 전파 전송의 물리학을 이해해야 했습니다. 그 결과 라디오에는 손잡이가 하나만 남았습니다.

이제 2019년에는 어떤 라디오를 할까요? 차 안에서는 라디오 수신기가 모든 전파와 방송국 이름을 찾아냅니다. 프로세스의 물리학은 100년 동안 변하지 않았지만 사용 편의성은 바뀌었습니다. 지금뿐만 아니라 이미 1980년에 Azimov와의 인터뷰가 있었을 때 모두가 라디오를 사용했고 아무도 그것이 어떻게 작동하는지 생각하지 않았습니다. 그것은 항상 효과가 있었습니다. 그것은 당연합니다.

Azimov는 컴퓨터에서도 마찬가지일 것이라고 말했습니다. 사용 편의성이 높아집니다. 1980년에는 컴퓨터 버튼을 누르는 방법을 교육받아야 했지만, 미래에는 그렇지 않을 것입니다.

Kubernetes와 인프라를 사용하면 사용 편의성도 크게 향상될 것이라고 생각합니다. 제 생각에는 이것은 명백합니다. 그것은 표면에 있습니다.

엔지니어는 어떻게 해야 하나요?

— 그러면 Kubernetes를 지원하는 엔지니어와 시스템 관리자는 어떻게 되나요?

드미트리: 1C 도래 이후 회계사에게 무슨 일이 일어났나요? 거의 같습니다. 그 전에는 종이에 의존했지만 이제는 프로그램에 포함되어 있습니다. 노동 생산성은 수십 배로 증가했지만 노동 자체는 사라지지 않았습니다. 이전에는 전구 하나를 조이는 데 10명의 엔지니어가 필요했다면 이제는 한 명이면 충분합니다.

제가 보기에 소프트웨어의 양과 작업의 수는 이제 새로운 DevOps가 등장하고 효율성이 증가하는 것보다 더 빠른 속도로 증가하고 있는 것 같습니다. 현재 시장에는 특별한 부족 현상이 있으며 오랜 시간 지속될 것입니다. 나중에는 모든 것이 일종의 정상 상태로 돌아가 작업 효율성이 증가하고, 서버리스가 점점 더 많아지고, 뉴런이 Kubernetes에 연결되어 필요에 따라 정확하게 모든 리소스를 선택하고 일반적으로 필요한대로 모든 것을 스스로 수행하십시오. 그 사람은 한 발 물러나 방해하지 마십시오.

하지만 누군가는 여전히 결정을 내려야 합니다. 이 사람의 자격과 전문성 수준이 더 높다는 것은 분명합니다. 요즘 회계 부서에서는 손이 피곤하지 않도록 장부를 보관하는 직원 10명이 필요하지 않습니다. 단순히 필요하지 않습니다. 많은 문서가 전자문서관리시스템을 통해 자동으로 스캔되고 인식됩니다. 이미 훨씬 뛰어난 기술과 좋은 이해력을 갖춘 똑똑한 최고 회계사 한 명이면 충분합니다.

일반적으로 이는 모든 산업에 적용되는 방식입니다. 자동차도 마찬가지입니다. 이전에는 자동차 한 대에 정비사 한 명과 운전자 세 명이 있었습니다. 오늘날 자동차 운전은 우리 모두가 매일 참여하는 간단한 과정입니다. 누구도 자동차가 복잡한 것이라고 생각하지 않습니다.

DevOps 또는 시스템 엔지니어링은 사라지지 않을 것입니다. 높은 수준의 작업과 효율성이 향상될 것입니다.

— 실제로 일이 늘어날 것이라는 흥미로운 이야기도 들었습니다.

드미트리: 물론이죠, 백퍼센트! 우리가 작성하는 소프트웨어의 양이 지속적으로 증가하고 있기 때문입니다. 우리가 소프트웨어로 해결하는 문제의 수는 지속적으로 증가하고 있습니다. 작업량이 증가하고 있습니다. 이제 DevOps 시장은 극도로 과열되었습니다. 이는 급여 기대치에서 확인할 수 있습니다. 좋게 말하면 X를 원하는 후배, 1,5X를 원하는 중간, 2X를 원하는 선배가 있어야 합니다. 그리고 이제 모스크바 DevOps 연봉 시장을 보면 후배는 X에서 3X까지를 원하고 선배는 X에서 3X까지를 원합니다.

비용이 얼마나 드는지는 아무도 모릅니다. 급여 수준은 귀하의 자신감에 의해 측정됩니다. 솔직히 말하면 극도로 과열된 시장인 완전한 미친 집입니다.

물론 이 상황은 곧 바뀔 것입니다. 어느 정도 포화 상태가 발생해야 합니다. 소프트웨어 개발의 경우는 그렇지 않습니다. 모든 사람이 개발자가 필요하고 모든 사람이 좋은 개발자가 필요하다는 사실에도 불구하고 시장은 누가 무엇을 할 가치가 있는지 이해합니다. 업계는 정착했습니다. 요즘 DevOps는 그렇지 않습니다.

— 제가 들은 바에 따르면 현재의 시스템 관리자는 너무 걱정하지 않아도 되지만 내일은 일이 더 많아지지만 자격이 더 높아질 것이라는 사실을 대비하고 실력을 업그레이드해야 할 때라는 결론이 나왔습니다.

드미트리: 백퍼센트. 일반적으로 우리는 2019년에 살고 있으며 삶의 법칙은 다음과 같습니다. 평생 학습 - 우리는 평생 동안 배웁니다.. 이제 모든 사람이 이미 이것을 알고 느끼고 있는 것 같지만, 아는 것만으로는 충분하지 않습니다. 해야 합니다. 매일 우리는 변화해야 합니다. 만약 우리가 이것을 하지 않는다면, 조만간 우리는 직업의 측면에서 배제될 것입니다.

180도 급회전에 대비하세요. 나는 무언가가 근본적으로 변하고, 새로운 것이 발명되는 상황을 배제하지 않습니다. 그런 일이 일어납니다. 깡충깡충 뛰다! -이제 우리는 다르게 행동합니다. 이에 대비하고 걱정하지 않는 것이 중요합니다. 내일 내가 하는 모든 일이 불필요한 것으로 판명될 수도 있습니다. 아무것도 아닙니다. 나는 평생 공부했고 다른 것을 배울 준비가 되어 있습니다. 문제가 되지 않습니다. 직업안정을 두려워할 필요는 없지만, 끊임없이 새로운 것을 배울 준비가 되어 있어야 합니다.

소원과 광고의 순간

- 소원이 있나요?

드미트리: 네, 몇 가지 소원이 있어요.

최초이자 상업성 - 구독 유튜브. 독자 여러분, YouTube로 이동하여 채널을 구독하세요. 약 한 달 안에 비디오 서비스의 활발한 확장을 시작할 예정입니다. 실제적인 것부터 실험실까지, 심층적인 기초 이론적인 것, 현장에서 Kubernetes를 사용하는 방법에 이르기까지 Kubernetes에 대한 많은 교육 콘텐츠를 개방적이고 다양하게 보유하게 될 것입니다. 원칙과 패턴의 수준.

두 번째 상업 소원 - 가다 GitHub의 별을 붙이는 이유는 우리가 별을 먹기 때문입니다. 별을 주지 않으면 우리는 먹을 것이 없습니다. 컴퓨터 게임의 마나와 같습니다. 우리는 뭔가를 하고, 하고, 시도하고, 누군가는 이것이 끔찍한 자전거라고 말하고, 누군가는 모든 것이 완전히 잘못되었다고 말하지만 우리는 계속해서 절대적으로 정직하게 행동합니다. 우리는 문제를 보고, 해결하고, 경험을 공유합니다. 그러므로 우리에게 별을 주십시오. 그것은 여러분에게서 떠나지 않고 우리에게 올 것입니다. 왜냐하면 우리가 그것을 먹고 있기 때문입니다.

세 번째, 중요하지만 더 이상 상업적이지 않은 소원 - 동화를 믿지 마세요. 당신은 전문가입니다. DevOps는 매우 진지하고 책임감 있는 직업입니다. 직장에서 놀지 마세요. 클릭해 보시면 이해하실 것입니다. 당신이 병원에 왔는데 의사가 당신을 대상으로 실험을 하고 있다고 상상해 보십시오. 나는 이것이 누군가에게 불쾌감을 줄 수 있다는 것을 이해합니다. 그러나 이것은 아마도 당신에 관한 것이 아니라 다른 사람에 관한 것입니다. 다른 사람들에게도 그만하라고 말하세요. 이는 우리 모두의 삶을 정말로 망치게 됩니다. 많은 사람들이 운영, 관리자 및 DevOps를 또 뭔가를 망친 친구로 취급하기 시작합니다. 이것은 우리가 놀러 갔다는 사실 때문에 가장 자주 "깨졌"고, 이것이 바로 그것이고, 그것이 바로 그 방식이라는 냉담한 의식으로 보지 않았습니다.

그렇다고 해서 실험을 하면 안 된다는 뜻은 아닙니다. 우리는 실험을 해야 하고 스스로 해내야 합니다. 솔직히 말해서 우리 자신도 때때로 게임을합니다. 물론 이것은 매우 나쁘지만 인간이 우리에게 외계인은 없습니다. 2019년은 프로덕션 게임이 아닌 진지하고 신중한 실험의 해로 선언합시다. 아마도 그럴 것입니다.

- 매우 감사합니다!

드미트리: 시간을 내어 인터뷰에 응해주신 비탈리씨, 감사드립니다. 사랑하는 독자 여러분, 갑자기 이 지경에 이르게 되셨다면 진심으로 감사드립니다. 우리가 당신에게 최소한 몇 가지 생각을 가져왔기를 바랍니다.

인터뷰에서 Dmitry는 werf 문제를 다루었습니다. 이제 이것은 거의 모든 문제를 해결하는 만능 스위스 칼입니다. 그러나 항상 그런 것은 아닙니다. ~에 DevOpsConf  축제에서 RIT++ Dmitry Stolyarov가 이 도구에 대해 자세히 설명합니다. 보고서에서 "werf는 Kubernetes의 CI/CD용 도구입니다." Kubernetes의 문제와 숨겨진 뉘앙스, 이러한 어려움을 해결하기 위한 옵션 및 Werf의 현재 구현에 대한 자세한 내용 등 모든 것이 있습니다. 27월 28일과 XNUMX일에 우리와 함께하면 완벽한 도구를 만들 수 있습니다.

출처 : habr.com