Kubernetes의 인기 증가에 대해

헤이 하브르!

여름이 끝날 무렵, 우리는 이 주제에 대해 계속해서 연구하고 있음을 상기시키고 싶습니다. Kubernetes 그리고 XNUMX월 초에 이 프로젝트의 상황을 보여주는 Stackoverflow의 기사를 게시하기로 결정했습니다.

독서를 즐기십시오!

이 글을 쓰는 시점에서 쿠버네티스의 시대는 대략 XNUMX년 정도다. 여섯 살, 그리고 지난 XNUMX년 동안 인기가 너무 높아져 꾸준히 상위권에 랭크되었습니다. 가장 좋아하는 플랫폼. 쿠버네티스는 올해 XNUMX위를 차지했습니다. 요약하자면, Kubernetes는 컨테이너화된 워크로드를 실행하고 조정하기 위해 설계된 플랫폼입니다.

컨테이너는 원래 공정을 격리하기 위한 특수 설계에서 유래되었습니다. Linux2007년부터 컨테이너에는 다음이 포함되었습니다. cgroup, 2002년 이후 – 네임스페이스. 컨테이너는 2008년에 출시되면서 훨씬 더 좋게 설계되었습니다. LXC, Google은 다음과 같은 자체 내부 기업 메커니즘을 개발했습니다. 보그, 여기서 "모든 작업은 컨테이너에서 수행됩니다." 2013년에는 Docker가 처음 출시되었고 컨테이너가 마침내 인기 있는 대량 솔루션이 되었습니다. 당시 컨테이너 오케스트레이션을 위한 주요 도구는 메 소스, 그는 큰 인기를 얻지는 못했지만. Kubernetes는 2015년에 처음 출시된 후 이 도구가 컨테이너 오케스트레이션 분야의 사실상 표준이 되었습니다.

Kubernetes가 인기 있는 이유를 이해하기 위해 몇 가지 질문에 답해 보겠습니다. 개발자들이 애플리케이션을 프로덕션 환경에 배포하는 방법에 대해 마지막으로 합의한 때는 언제였습니까? 기본적으로 제공되는 도구를 사용하는 개발자를 알고 있는 개발자는 몇 명입니까? 오늘날 애플리케이션의 작동 방식을 이해하지 못하는 클라우드 관리자가 얼마나 됩니까? 이 기사에서는 이러한 질문에 대한 답을 살펴보겠습니다.

YAML로서의 인프라

Puppet과 Chef에서 Kubernetes로 전환한 세계에서 가장 큰 변화 중 하나는 "코드로서의 인프라"에서 특히 YAML과 같은 "데이터로서의 인프라"로의 이동이었습니다. 포드, 구성, 배포된 인스턴스, 볼륨 등을 포함하는 Kubernetes의 모든 리소스는 YAML 파일에서 쉽게 설명할 수 있습니다. 예를 들어:

apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80

이 보기를 사용하면 DevOps 또는 SRE 전문가가 Python 또는 Javascript와 같은 언어로 코드를 작성하지 않고도 워크로드를 완벽하게 표현할 수 있습니다.

인프라를 데이터로 구성하면 다음과 같은 다른 이점이 있습니다.

• GitOps 또는 Git Operations 버전 제어. 이 접근 방식을 사용하면 모든 Kubernetes YAML 파일을 git 리포지토리에 보관할 수 있으므로 언제 변경했는지, 누가 변경했는지, 정확히 무엇이 변경되었는지 추적할 수 있습니다. 이는 특히 직원들이 필요한 리소스를 찾아야 하는 곳에서 모호성을 제거함으로써 조직 전체의 운영 투명성을 높이고 운영 효율성을 향상시킵니다. 동시에 간단히 풀 요청을 병합하여 Kubernetes 리소스를 자동으로 변경하는 것이 더 쉬워졌습니다.
• 확장성. 리소스가 YAML로 정의되면 클러스터 운영자가 Kubernetes 리소스에서 하나 또는 두 개의 숫자를 변경하여 확장 방법을 변경하는 것이 매우 쉬워집니다. Kubernetes는 낮은 수준과 높은 수준의 트래픽을 처리하기 위해 특정 배포 구성에 필요한 최소 및 최대 포드 수를 편리하게 결정하는 데 사용할 수 있는 포드의 수평 자동 크기 조정을 위한 메커니즘을 제공합니다. 예를 들어 트래픽 급증으로 인해 추가 용량이 필요한 구성을 배포한 경우 maxReplicas를 10에서 20으로 변경할 수 있습니다.

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

• 보안 및 관리. YAML은 Kubernetes에서 사물이 배포되는 방식을 평가하는 데 적합합니다. 예를 들어 주요 보안 문제는 워크로드가 관리자가 아닌 사용자로 실행되는지 여부와 관련됩니다. 이 경우 다음과 같은 도구가 필요할 수 있습니다. 콘테스트, YAML/JSON 유효성 검사기 및 정책 에이전트 열기, 컨텍스트를 확인하는 정책 유효성 검사기 보안컨텍스트 워크로드에서 컨테이너가 관리자 권한으로 실행되는 것을 허용하지 않습니다. 이것이 필요한 경우 사용자는 간단한 정책을 적용할 수 있습니다. 레고, 이렇게 :

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}

• 클라우드 제공업체와의 통합 옵션. 오늘날 첨단 기술에서 가장 주목할만한 추세 중 하나는 퍼블릭 클라우드 제공업체에서 워크로드를 실행하는 것입니다. 구성 요소 사용 클라우드 제공업체 Kubernetes를 사용하면 모든 클러스터가 실행되는 클라우드 공급자와 통합될 수 있습니다. 예를 들어, 사용자가 AWS의 Kubernetes에서 애플리케이션을 실행하고 서비스를 통해 해당 애플리케이션을 노출하려는 경우 클라우드 공급자는 자동으로 서비스를 생성하도록 돕습니다. LoadBalancer자동으로 로드 밸런서를 제공합니다. 아마존 탄력적 로드 밸런서트래픽을 애플리케이션 포드로 리디렉션합니다.

확장성

Kubernetes는 확장성이 매우 뛰어나며 개발자들은 이를 좋아합니다. Pod, 배포 등 사용 가능한 리소스 세트가 있습니다. StatefulSets, 비밀, ConfigMaps, 등. 사실, 사용자와 개발자는 양식에 다른 리소스를 추가할 수 있습니다. 사용자 정의 리소스 정의.

예를 들어 리소스를 정의하려는 경우 CronTab, 그러면 다음과 같이 할 수 있습니다:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.my.org
spec:
  group: my.org
  versions:
    - name: v1
      served: true
      storage: true
      Schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                  pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

나중에 다음과 같은 CronTab 리소스를 만들 수 있습니다.

apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5

Kubernetes의 확장성을 위한 또 다른 옵션은 개발자가 자신의 명령문을 작성할 수 있다는 것입니다. 연산자 "에 따라 작동하는 Kubernetes 클러스터의 특수 프로세스입니다.제어 회로" 운영자의 도움으로 사용자는 Kubernetes API와 정보를 교환하여 CRD(사용자 정의 리소스 정의) 관리를 자동화할 수 있습니다.

커뮤니티에는 개발자가 자신만의 연산자를 쉽게 만들 수 있는 여러 도구가 있습니다. 그 중 - 연산자 프레임워크 과 연산자 SDK. 이 SDK는 개발자가 신속하게 연산자 생성을 시작할 수 있는 기반을 제공합니다. 다음과 같이 명령줄에서 시작할 수 있다고 가정해 보겠습니다.

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

그러면 YAML 파일 및 Golang 코드를 포함하여 운영자를 위한 모든 상용구 코드가 생성됩니다.

.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.go

그런 다음 다음과 같이 필요한 API와 컨트롤러를 추가할 수 있습니다.

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

그런 다음 마지막으로 연산자를 조합하여 컨테이너 레지스트리로 보냅니다.

$ operator-sdk build your.container.registry/youruser/myapp-operator

개발자가 더 많은 제어를 원하는 경우 Go 파일의 상용구 코드를 변경할 수 있습니다. 예를 들어 컨트롤러의 세부 사항을 수정하려면 파일을 변경할 수 있습니다. controller.go.

또 다른 프로젝트 EVERYWHERE를 사용하면 선언적 YAML 파일만 사용하여 명령문을 생성할 수 있습니다. 예를 들어 Apache Kafka의 연산자는 대략적으로 정의됩니다. 그래서. 이를 사용하면 몇 가지 명령만으로 Kubernetes 위에 Kafka 클러스터를 설치할 수 있습니다.

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

그런 다음 다른 명령을 사용하여 구성합니다.

$ kubectl kudo install kafka --instance=my-kafka-name 
            -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 
            -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m 
            -p BROKER_COUNT=5 -p BROKER_MEM=4096m 
            -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 
            -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20

혁신

지난 몇 년 동안 주요 Kubernetes 릴리스는 몇 달마다 출시되었습니다. 즉, 연간 XNUMX~XNUMX개의 주요 릴리스가 출시되었습니다. 각각에 도입된 새로운 기능의 수는 줄어들지 않습니다. 더욱이, 이 어려운 시기에도 둔화될 조짐은 보이지 않습니다. 현재 상황을 살펴보십시오. Github의 Kubernetes 프로젝트 활동.

새로운 기능을 사용하면 다양한 워크로드 전반에 걸쳐 작업을 보다 유연하게 클러스터링할 수 있습니다. 또한 프로그래머는 애플리케이션을 프로덕션에 직접 배포할 때 더 큰 제어력을 누릴 수 있습니다.

커뮤니티

Kubernetes 인기의 또 다른 주요 측면은 커뮤니티의 강점입니다. 2015년 버전 1.0이 출시되자 Kubernetes는 다음의 후원을 받았습니다. 클라우드 네이티브 컴퓨팅 재단.

다양한 커뮤니티도 있어요 SIG (Special Interest Groups)은 프로젝트가 발전함에 따라 Kubernetes의 다양한 영역에서 작업하는 데 중점을 두었습니다. 이러한 그룹은 지속적으로 새로운 기능을 추가하여 Kubernetes 작업을 더욱 편리하고 편리하게 만들고 있습니다.

Cloud Native Foundation은 또한 이 글을 쓰는 시점에 세계 최대 규모의 오픈 소스 컨퍼런스인 CloudNativeCon/KubeCon을 주최합니다. 일반적으로 XNUMX년에 XNUMX회 개최되는 이 행사에는 Kubernetes와 생태계를 개선하고 XNUMX개월마다 나타나는 새로운 기능을 배우고자 하는 수천 명의 전문가가 모입니다.

게다가 Cloud Native Foundation은 기술감독위원회, SIG와 함께 신규 및 기존 검토 프로젝트 클라우드 생태계에 초점을 맞춘 자금입니다. 이러한 프로젝트의 대부분은 Kubernetes의 강점을 향상하는 데 도움이 됩니다.

마지막으로, 사람들이 함께 뭉치면서 동시에 새로운 사람들을 환영하는 전체 커뮤니티의 의식적인 노력이 없었다면 Kubernetes는 지금처럼 성공하지 못할 것이라고 믿습니다.

미래

앞으로 개발자가 처리해야 할 주요 과제 중 하나는 코드가 실행되는 인프라가 아닌 코드 자체의 세부 사항에 집중할 수 있는 능력입니다. 이러한 트렌드에 부합하는 서버리스 아키텍처 패러다임, 이는 오늘날 최고의 것 중 하나입니다. 고급 프레임워크가 이미 존재합니다. 원어민 и 오픈파스, Kubernetes를 사용하여 개발자로부터 인프라를 추상화합니다.

이 기사에서 우리는 Kubernetes의 현재 상태를 표면적으로만 살펴보았습니다. 사실 이는 빙산의 일각에 불과합니다. Kubernetes 사용자는 원하는 대로 다양한 리소스, 기능 및 구성을 사용할 수 있습니다.

출처 : habr.com