컨테이너에서 컨베이어로: CRI-O는 이제 OpenShift Container Platform 4에서 기본값입니다.

플랫폼 레드햇 오픈시프트 컨테이너 플랫폼 4 생성을 간소화할 수 있습니다. 컨테이너 배포용 호스트, 클라우드 서비스 제공업체의 인프라, 가상화 플랫폼 또는 베어메탈 시스템을 포함합니다. 진정한 클라우드 기반 플랫폼을 만들기 위해 우리는 사용되는 모든 요소를 ​​엄격하게 제어하여 복잡한 자동화 프로세스의 신뢰성을 높여야 했습니다.

확실한 해결책은 Red Hat Enterprise Linux CoreOS(Red Hat Enterprise Linux의 변형)와 CRI-O를 표준으로 사용하는 것이었습니다. 그 이유는 다음과 같습니다.

항해라는 주제는 Kubernetes와 컨테이너의 작업을 설명할 때 비유를 찾는 데 매우 좋은 주제이므로 CoreOS와 CRI-O가 해결하는 비즈니스 문제에 대해 예를 사용하여 이야기해 보겠습니다. 리깅 블록 생산을 위한 브루넬의 발명품. 1803년에 마크 브루넬(Marc Brunel)은 성장하는 영국 해군의 요구에 맞춰 100개의 리깅 블록을 생산하라는 임무를 받았습니다. 리깅 블록(rigging block)은 돛에 로프를 부착하는 데 사용되는 리깅 유형입니다. 19세기 초까지 이러한 블록은 수작업으로 제작되었지만 Brunel은 생산을 자동화하고 공작 기계를 사용하여 표준화된 블록을 생산하기 시작했습니다. 이 프로세스의 자동화는 생성된 블록이 본질적으로 동일하고, 파손된 경우 쉽게 교체할 수 있으며, 대량으로 생산할 수 있음을 의미했습니다.

이제 Brunel이 20개의 서로 다른 선박 모델(Kubernetes 버전)과 완전히 다른 해류와 바람이 있는 XNUMX개의 서로 다른 행성(클라우드 공급자)에 대해 이 작업을 수행해야 한다고 상상해 보세요. 또한 선장(클러스터 운영을 관리하는 운영자)의 관점에서 탐색이 수행되는 행성에 관계없이 모든 선박(OpenShift 클러스터)이 동일하게 행동해야 했습니다. 해상 비유를 계속하자면, 선장은 선박에 어떤 종류의 리깅 블록(CRI-O)이 사용되는지 전혀 신경 쓰지 않습니다. 그들에게 가장 중요한 것은 이러한 블록이 강력하고 신뢰할 수 있다는 것입니다.

클라우드 플랫폼인 OpenShift 4는 매우 유사한 비즈니스 과제에 직면해 있습니다. 클러스터를 생성할 때, 노드 중 하나에 오류가 발생하는 경우 또는 클러스터를 확장할 때 새 노드를 생성해야 합니다. 새 노드가 생성되고 초기화되면 CRI-O를 포함한 중요한 호스트 구성 요소를 그에 따라 구성해야 합니다. 다른 생산과 마찬가지로 처음부터 '원료'가 공급되어야 합니다. 선박의 경우 원자재는 금속과 목재이다. 그러나 OpenShift 4 클러스터에 컨테이너를 배포하기 위한 호스트를 생성하는 경우 구성 파일과 API 제공 서버가 입력으로 필요합니다. 그런 다음 OpenShift는 전체 수명 주기에 걸쳐 필요한 수준의 자동화를 제공하여 최종 사용자에게 필요한 제품 지원을 제공함으로써 플랫폼에 대한 투자를 회수합니다.

OpenShift 4는 모든 주요 클라우드 컴퓨팅 제공업체, 가상화 플랫폼 및 베어메탈 시스템에 대해 플랫폼(버전 4.X용)의 전체 수명 주기 동안 시스템을 편리하게 업데이트할 수 있는 기능을 제공하는 방식으로 만들어졌습니다. 이를 위해서는 상호 교환 가능한 요소를 기반으로 노드를 생성해야 합니다. 클러스터에 새 버전의 Kubernetes가 필요한 경우 CoreOS에서 해당 버전의 CRI-O도 수신됩니다. CRI-O 버전은 Kubernetes에 직접 연결되어 있으므로 테스트, 문제 해결 또는 지원 목적을 위한 모든 순열이 크게 단순화됩니다. 또한 이 접근 방식은 최종 사용자와 Red Hat의 비용을 절감합니다.

이는 Kubernetes 클러스터에 대한 근본적으로 새로운 사고 방식이며 매우 유용하고 매력적인 새로운 기능을 계획하기 위한 기반을 마련합니다. CRI-O(Container Runtime Interface - Open Container Initiative, 약칭 CRI-OCI)는 OpenShift 작업에 필요한 노드 대량 생성을 위한 가장 성공적인 선택으로 판명되었습니다. CRI-O는 이전에 사용된 Docker 엔진을 대체하여 OpenShift 사용자에게 경제적이고 안정적이며 단순하고 지루함 – 네, 맞습니다. Kubernetes 작업을 위해 특별히 제작된 지루한 컨테이너 엔진입니다.

오픈 컨테이너의 세계

세계는 오랫동안 개방형 컨테이너를 향해 나아가고 있습니다. Kubernetes에서든 하위 수준에서든 컨테이너 표준 개발 모든 수준에서 혁신 생태계가 탄생합니다.

모든 것은 Open Containers Initiative의 창설로 시작되었습니다. 6 월에 2015. 이 작업 초기 단계에서 컨테이너 사양이 형성되었습니다. 영상 и 런타임 환경. 이를 통해 도구가 단일 표준을 사용할 수 있게 되었습니다. 컨테이너 이미지 그리고 그들과 함께 작업하기 위한 통일된 형식이 필요합니다. 사양은 나중에 추가되었습니다. 분포, 사용자가 쉽게 공유할 수 있도록 함 컨테이너 이미지.

그런 다음 Kubernetes 커뮤니티는 플러그형 인터페이스에 대한 단일 표준을 개발했습니다. 컨테이너 런타임 인터페이스(CRI). 덕분에 쿠버네티스 사용자들은 도커 외에도 다양한 엔진을 연결해 컨테이너와 연동할 수 있었다.

Red Hat과 Google의 엔지니어들은 CRI 프로토콜을 통해 Kubelet 요청을 수용할 수 있는 컨테이너 엔진에 대한 시장의 필요성을 확인하고 위에서 언급한 OCI 사양과 호환되는 컨테이너를 출시했습니다. 그래서 OCID가 나타났다. 그런데 죄송합니다. 이 자료를 CRI-O에 헌정한다고 하지 않았나요? 사실 출시되자마자 그렇죠 버전 1.0 프로젝트 이름이 CRI-O로 변경되었습니다.

그림. 1.

CRI-O와 CoreOS를 통한 혁신

OpenShift 4 플랫폼이 출시되면서 변경되었습니다. 컨테이너 엔진, 플랫폼에서 기본적으로 사용되는 Docker는 Kubernetes와 병렬로 개발되는 컨테이너를 실행하기 위한 비용 효율적이고 안정적이며 간단하고 지루한 환경을 제공하는 CRI-O로 대체되었습니다. 이는 클러스터 지원 및 구성을 크게 단순화합니다. 컨테이너 엔진과 호스트의 구성과 관리는 OpenShift 4 내에서 자동화됩니다.

잠깐, 이건 어때?

그렇습니다. OpenShift 4의 등장으로 더 이상 개별 호스트에 연결하고 컨테이너 엔진을 설치하고, 스토리지를 구성하고, 검색 서버를 구성하거나 네트워크를 구성할 필요가 없습니다. OpenShift 4 플랫폼은 다음을 사용하도록 완전히 재설계되었습니다. 연산자 프레임워크 최종 사용자 애플리케이션 측면뿐만 아니라 이미지 배포, 시스템 구성 또는 업데이트 설치와 같은 기본 플랫폼 수준 작업 측면에서도 마찬가지입니다.

Kubernetes는 항상 사용자가 원하는 상태를 정의하고 다음을 사용하여 애플리케이션을 관리할 수 있도록 허용했습니다. 컨트롤러, 실제 상태가 목표 상태와 최대한 일치하는지 확인합니다. 이것 목표상태와 실제상태 접근 개발 및 운영 관점 모두에서 큰 기회를 열어줍니다. 개발자는 다음과 같이 필요한 상태를 정의할 수 있습니다. 그것을 통과 YAML 또는 JSON 파일 형식으로 운영자에게 전달하면 운영자는 프로덕션 환경에서 필요한 애플리케이션 인스턴스를 생성할 수 있으며 이 인스턴스의 작동 상태는 지정된 인스턴스와 완전히 일치합니다.

OpenShift 4는 플랫폼의 Operator를 사용하여 RHEL CoreOS 및 CRI-O 관리에 이 새로운 패러다임(세트 및 실제 상태 개념 사용)을 제공합니다. 운영 체제 및 컨테이너 엔진의 버전을 구성하고 관리하는 작업은 소위 말하는 방식을 사용하여 자동화됩니다. MCO(머신 구성 운영자). MCO는 설치의 마지막 단계와 후속 설치 후 작업(4일차 작업)을 기본적으로 자동화하여 클러스터 관리자의 작업을 크게 단순화합니다. 이 모든 것이 OpenShift XNUMX를 진정한 클라우드 플랫폼으로 만듭니다. 이에 대해서는 잠시 후에 다루겠습니다.

컨테이너 실행

사용자는 Tech Preview 상태의 버전 3.7부터 일반 사용 가능 상태(현재 지원됨)의 버전 3.9부터 OpenShift 플랫폼에서 CRI-O 엔진을 사용할 수 있었습니다. 또한 Red Hat은 대규모로 프로덕션 워크로드 실행을 위한 CRI-O 버전 3.10부터 OpenShift Online에서. 이 모든 것을 통해 CRI-O 작업 팀은 대규모 Kubernetes 클러스터에서 컨테이너를 대량 출시하는 데 있어 광범위한 경험을 얻을 수 있었습니다. Kubernetes가 CRI-O를 사용하는 방법에 대한 기본적인 이해를 얻으려면 아키텍처 작동 방식을 보여주는 다음 그림을 살펴보겠습니다.

쌀. 2. Kubernetes 클러스터에서 컨테이너가 작동하는 방식

CRI-O는 새 노드를 초기화하고 OpenShift 플랫폼의 새 버전을 출시할 때 전체 최상위 수준을 동기화하여 새 컨테이너 호스트 생성을 단순화합니다. 전체 플랫폼의 개정은 트랜잭션 업데이트/롤백을 허용하고 컨테이너 테일 코어, 컨테이너 엔진, 노드(Kubelets) 및 Kubernetes 마스터 노드 간의 종속성 교착 상태를 방지합니다. 제어 및 버전 관리를 통해 모든 플랫폼 구성 요소를 중앙에서 관리함으로써 상태 A에서 상태 B로의 명확한 경로가 항상 존재합니다. 이는 업데이트 프로세스를 단순화하고, 보안을 향상시키며, 성능 보고를 개선하고, 새 버전의 업데이트 및 설치 비용을 줄이는 데 도움이 됩니다. .

교체 요소의 위력 입증

앞서 언급한 것처럼 Machine Config Operator를 사용하여 OpenShift 4에서 컨테이너 호스트와 컨테이너 엔진을 관리하면 이전에는 Kubernetes 플랫폼에서 불가능했던 새로운 수준의 자동화가 제공됩니다. 새로운 기능을 시연하기 위해 crio.conf 파일을 변경하는 방법을 보여드리겠습니다. 용어로 인한 혼동을 피하려면 결과에 집중하십시오.

먼저 컨테이너 런타임 구성인 Container Runtime Config를 만들어 보겠습니다. CRI-O의 구성을 나타내는 Kubernetes 리소스로 생각하십시오. 실제로 이는 OpenShift 클러스터의 일부로 RHEL CoreOS 시스템에 배포되는 구성인 MachineConfig라는 항목의 특수 버전입니다.

ContainerRuntimeConfig라고 하는 이 사용자 정의 리소스는 클러스터 관리자가 CRI-O를 더 쉽게 구성할 수 있도록 만들어졌습니다. 이 도구는 MachineConfigPool 설정에 따라 특정 노드에만 적용될 수 있을 만큼 강력합니다. 동일한 목적을 수행하는 기계 그룹으로 생각하십시오.

/etc/crio/crio.conf 파일에서 변경할 마지막 두 줄을 확인하세요. 이 두 줄은 crio.conf 파일의 줄과 매우 유사합니다.

vi ContainerRuntimeConfig.yaml

결론 :

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: set-log-and-pid
spec:
 machineConfigPoolSelector:
   matchLabels:
     debug-crio: config-log-and-pid
 containerRuntimeConfig:
   pidsLimit: 2048
   logLevel: debug

이제 이 파일을 Kubernetes 클러스터에 푸시하고 실제로 생성되었는지 확인해 보겠습니다. 작업은 다른 Kubernetes 리소스와 정확히 동일합니다.

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

결론 :

NAME              AGE
set-log-and-pid   22h

ContainerRuntimeConfig를 생성한 후에는 MachineConfigPool 중 하나를 수정하여 클러스터의 특정 머신 그룹에 이 구성을 적용하겠다는 신호를 Kubernetes에 보내야 합니다. 이 경우 마스터 노드에 대한 MachineConfigPool을 변경합니다.

oc edit MachineConfigPool/master

결론(명확성을 위해 주요 본질은 남음):

...
metadata:
 creationTimestamp: 2019-04-10T23:42:28Z
 generation: 1
 labels:
   debug-crio: config-log-and-pid
   operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...

이 시점에서 MCO는 클러스터에 대한 새 crio.conf 파일을 생성하기 시작합니다. 이 경우 Kubernetes API를 사용하여 완전히 완료된 구성 파일을 볼 수 있습니다. ContainerRuntimeConfig는 MachineConfig의 특수 버전일 뿐이므로 MachineConfigs에서 관련 줄을 보면 결과를 확인할 수 있습니다.

oc get MachineConfigs | grep rendered

결론 :

rendered-master-c923f24f01a0e38c77a05acfd631910b                  4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626                  4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62                  4.0.22-201904011459-dirty 2.2.0 16h

마스터 노드에 대한 결과 구성 파일은 원래 구성보다 최신 버전이었습니다. 이를 보려면 다음 명령을 실행하십시오. 지나가면서 우리는 이것이 아마도 Kubernetes 역사상 최고의 단일 라이너 중 하나라는 점에 주목합니다.

python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid

결론 :

pids_limit = 2048

이제 모든 마스터 노드에 구성이 적용되었는지 확인해 보겠습니다. 먼저 클러스터의 노드 목록을 얻습니다.

oc get node | grep master

Output:

ip-10-0-135-153.us-east-2.compute.internal   Ready master 23h v1.12.4+509916ce1

ip-10-0-154-0.us-east-2.compute.internal     Ready master 23h v1.12.4+509916ce1

ip-10-0-166-79.us-east-2.compute.internal    Ready master 23h v1.12.4+509916ce1

이제 설치된 파일을 살펴보겠습니다. ContainerRuntimeConfig 리소스에 지정한 pid 및 debug 지시문에 대한 새 값으로 파일이 업데이트된 것을 확인할 수 있습니다. 우아함 그 자체:

oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’

결론 :

...
pids_limit = 2048
...
log_level = "debug"
...

클러스터에 대한 이러한 모든 변경 사항은 SSH를 실행하지 않고도 이루어졌습니다. 모든 작업은 Kuberentes 마스터 노드에 접속하여 이루어졌습니다. 즉, 이러한 새 매개변수는 마스터 노드에서만 구성되었습니다. 작업자 노드는 변경되지 않았으며, 이는 상호 교환 가능한 요소가 있는 컨테이너 호스트 및 컨테이너 엔진과 관련하여 지정된 상태와 실제 상태를 사용하는 Kubernetes 방법론의 이점을 보여줍니다.

위의 예는 4개의 프로덕션 노드가 있는 소규모 OpenShift Container Platform 3000 클러스터 또는 4개의 노드가 있는 대규모 프로덕션 클러스터를 변경할 수 있는 기능을 보여줍니다. 어떤 경우든 작업량은 동일하고 매우 작습니다. 단지 ContainerRuntimeConfig 파일을 구성하고 MachineConfigPool에서 하나의 레이블만 변경하면 됩니다. 또한 라이프사이클 전반에 걸쳐 Kubernetes를 실행하는 모든 버전의 OpenShift Container Platform XNUMX.X에서 이를 수행할 수 있습니다.

종종 기술 회사는 너무 빠르게 발전하여 기본 구성 요소에 대해 특정 기술을 선택하는 이유를 설명할 수 없습니다. 컨테이너 엔진은 역사적으로 사용자가 직접 상호 작용하는 구성 요소였습니다. 컨테이너 엔진의 출현과 함께 자연스럽게 컨테이너의 인기가 시작되었기 때문에 사용자들은 이에 대한 관심을 자주 보인다. 이것이 Red Hat이 CRI-O를 선택한 또 다른 이유입니다. 컨테이너는 이제 오케스트레이션에 초점을 맞춰 진화하고 있으며 CRI-O가 OpenShift 4로 작업할 때 최고의 경험을 제공한다는 사실을 발견했습니다.

출처 : habr.com