Kubernetes의 엔터프라이즈 버전인 OpenShift. 1 부

"Kubernetes와 OpenShift의 차이점은 무엇입니까?" – 이 질문은 부러워할 만큼 일관성을 가지고 발생합니다. 실제로 이것은 자동차가 엔진과 어떻게 다른지 묻는 것과 같습니다. 비유를 계속하면 자동차는 완제품이므로 문자 그대로 즉시 사용할 수 있습니다. 타고 갈 수 있습니다. 반면, 엔진이 당신을 어딘가로 데려가려면, 궁극적으로 같은 차를 얻기 위해서는 먼저 다른 많은 것들이 보완되어야 합니다.

따라서 Kubernetes는 OpenShift 브랜드 자동차(플랫폼)가 조립되어 목표를 달성하도록 도와주는 엔진입니다.

이 글에서는 다음과 같은 핵심 사항을 좀 더 자세히 살펴보고자 합니다.

• Kubernetes는 OpenShift 플랫폼의 핵심이며 100% 인증된 Kubernetes이며 완전히 오픈 소스이며 독점 특성이 전혀 없습니다. 간단히:
  • OpenShift 클러스터 API는 XNUMX% Kubernetes입니다.
  • 컨테이너가 다른 Kubernetes 시스템에서 실행되는 경우 변경 없이 OpenShift에서 실행됩니다. 응용 프로그램을 변경할 필요가 없습니다.
• OpenShift는 Kubernetes에 유용한 기능을 추가할 뿐만 아니라 자동차와 마찬가지로 OpenShift는 상자에서 꺼내자마자 즉시 생산에 투입될 수 있으며, 아래에서 볼 수 있듯이 개발자의 삶을 훨씬 더 쉽게 만들어 줍니다. 이것이 바로 OpenShift가 두 사람으로 통합된 이유입니다. 개발자의 관점에서 보면 성공적이고 잘 알려진 엔터프라이즈급 PaaS 플랫폼입니다. 동시에 산업 운영 관점에서 볼 때 매우 안정적인 서비스형 컨테이너 솔루션입니다.

OpenShift는 100% CNCF 인증을 받은 Kubernetes입니다.

OpenShift는 다음을 기반으로 합니다. 쿠버네티스 인증. 따라서 적절한 교육을 받은 후 사용자는 kubectl의 강력함에 놀라게 됩니다. 그리고 Kubernetes Cluster에서 OpenShift로 전환한 사람들은 kubeconfig를 OpenShift 클러스터로 리디렉션한 후 모든 기존 스크립트가 완벽하게 작동한다는 점이 정말 마음에 든다고 자주 말합니다.

아마도 OC라는 OpenShift의 명령줄 유틸리티에 대해 들어보셨을 것입니다. kubectl과 완벽하게 명령 호환되며, 여러 작업을 수행할 때 유용하게 사용할 수 있는 몇 가지 유용한 도우미를 제공합니다. 하지만 먼저 OC와 kubectl의 호환성에 대해 좀 더 살펴보겠습니다.

kubectl 명령
OC 팀

kubectl은 포드를 얻을
oc 포드 가져와

kubectl은 네임스페이스를 얻습니다.
oc 네임스페이스 가져오기

kubectl create -f 배포.yaml
oc 생성 -f 배포.yaml

OpenShift API에서 kubectl을 사용한 결과는 다음과 같습니다.

• kubectl get pods – 예상대로 Pod를 반환합니다.

• kubectl get 네임스페이스 – 예상대로 네임스페이스를 반환합니다.

kubectl create -f mydeployment.yaml 명령은 아래 비디오에 표시된 것처럼 다른 Kubernetes 플랫폼과 마찬가지로 kubernetes 리소스를 생성합니다.

즉, 모든 Kubernetes API는 100% 호환성을 유지하면서 OpenShift에서 완벽하게 사용할 수 있습니다. 그렇기 때문에 OpenShift는 CNCF(Cloud Native Computing Foundation)에서 인증된 Kubernetes 플랫폼으로 인정받았습니다.. 

OpenShift는 Kubernetes에 유용한 기능을 추가합니다.

Kubernetes API는 OpenShift에서 100% 사용할 수 있지만 표준 Kubernetes 유틸리티 kubectl에는 기능과 편의성이 분명히 부족합니다. 이것이 바로 Red Hat이 OC(OpenShift 클라이언트의 약어) 및 ODO(OpenShift DO, 이 유틸리티는 개발자를 대상으로 함)와 같은 유용한 기능과 명령줄 도구를 Kubernetes에 추가한 이유입니다.

1. OC 유틸리티 - Kubectl의 더욱 강력하고 편리한 버전

예를 들어 kubectl과 달리 새로운 네임스페이스를 생성하고 컨텍스트를 쉽게 전환할 수 있으며, 컨테이너 이미지를 빌드하고 소스 코드나 바이너리에서 직접 애플리케이션을 배포하는 등(Source-to-image, Source-to-image, s2i).

OC 유틸리티의 내장 도우미와 고급 기능이 일상 작업을 단순화하는 데 어떻게 도움이 되는지 예를 살펴보겠습니다.

첫 번째 예는 네임스페이스 관리입니다. 각 Kubernetes 클러스터에는 항상 여러 개의 네임스페이스가 있습니다. 일반적으로 개발 및 프로덕션 환경을 만드는 데 사용되지만, 예를 들어 각 개발자에게 개인 샌드박스를 제공하는 데에도 사용할 수 있습니다. 실제로 kubectl은 현재 공간의 컨텍스트에서 실행되기 때문에 개발자는 네임스페이스 간에 자주 전환해야 합니다. 따라서 kubectl의 경우 이를 위해 헬퍼 스크립트를 적극적으로 활용하는 경우가 많다. 하지만 OC를 사용할 때는 원하는 공간으로 전환하려면 "oc 프로젝트 네임스페이스"라고 말하면 됩니다.

필요한 네임스페이스가 무엇인지 기억하지 못하시나요? 문제 없습니다. "oc get projects"를 입력하면 전체 목록이 표시됩니다. 클러스터에 있는 제한된 네임스페이스 하위 집합에만 액세스할 수 있는 경우 이것이 어떻게 작동할지 궁금하십니까? 글쎄, kubectl은 RBAC가 클러스터의 모든 공간을 볼 수 있도록 허용하고 대규모 클러스터에서는 모든 사람에게 그러한 권한이 부여되지 않는 경우에만 이 작업을 올바르게 수행하기 때문입니다. 따라서 우리는 다음과 같이 대답합니다. OC의 경우 이는 전혀 문제가 되지 않으며 그러한 상황에서 전체 목록을 쉽게 생성할 것입니다. Openshift의 기업 지향성과 사용자 및 애플리케이션 측면에서 이 플랫폼의 우수한 확장성을 구성하는 것은 이러한 작은 것들입니다.

2. ODO - 개발자를 위한 kubectl의 향상된 버전

Kubernetes에 비해 Red Hat OpenShift가 개선된 또 다른 예는 ODO 명령줄 유틸리티입니다. 개발자를 위해 설계되었으며 원격 OpenShift 클러스터에 로컬 코드를 빠르게 배포할 수 있습니다. 또한 이미지를 다시 빌드, 등록 및 재배포할 필요 없이 모든 코드 변경 사항을 원격 OpenShift 클러스터의 컨테이너에 즉시 동기화하여 내부 프로세스를 간소화할 수 있습니다.

OC와 ODO가 어떻게 컨테이너와 Kubernetes 작업을 더 쉽게 만드는지 살펴보겠습니다.

kubectl을 기반으로 구축된 경우와 OC 또는 ODO를 사용하는 경우의 몇 가지 워크플로를 비교해 보세요.

• YAML을 구사하지 못하는 사용자를 위해 OpenShift에 코드 배포:

쿠버네티스/kubectl
$>git 클론 github.com/sclorg/nodejs-ex.git
1- 코드에서 이미지를 빌드하는 Dockerfile 만들기
-----
노드에서
WORKDIR /usr/src/app
COPY 패키지*.json ./
복사 index.js ./
복사 ./app ./app
npm 설치 실행
노출 3000
CMD [ “npm”, “시작” ] ————–
2- 이미지를 구축합니다
$>포드맨 빌드...
3- 레지스트리에 로그인
팟맨 로그인...
4- 레지스트리에 이미지 배치
포드맨 푸시
5- 애플리케이션 배포를 위한 yaml 파일 생성(deployment.yaml, service.yaml, ingress.yaml) - 이는 절대 최소값입니다.
6- 매니페스트 파일 배포:
Kubectl 적용 -f .

오픈시프트/oc
$> oc 새 앱 github.com/sclorg/nodejs-ex.git – our_application_name

오픈시프트/odo
$>git 클론 github.com/sclorg/nodejs-ex.git
$> odo 구성 요소 nodejs myapp 만들기
$>오도 푸시

• 컨텍스트 전환: 작업 네임스페이스 또는 작업 클러스터를 변경합니다.

쿠버네티스/kubectl
1- "myproject" 프로젝트에 대해 kubeconfig에서 컨텍스트를 생성합니다.
2- kubectl 세트 컨텍스트…

오픈시프트/oc
oc 프로젝트 “myproject”

품질 관리: “한 가지 흥미로운 기능이 아직 알파 버전으로 여기에 나타났습니다. 어쩌면 우리는 그것을 생산에 투입할 수 있을까요?”

경주용 자동차에 앉아 다음과 같은 말을 듣는다고 상상해 보십시오. "우리는 새로운 유형의 브레이크를 설치했는데 솔직히 말해서 브레이크의 신뢰성은 아직 괜찮지 않습니다... 하지만 걱정하지 마십시오. 코스 중에 적극적으로 개선할 것입니다. 챔피언십의.” 이 전망이 마음에 드시나요? Red Hat에 있는 우리는 왠지 별로 행복하지 않습니다. 🙂

따라서 우리는 알파 버전이 충분히 성숙되고 철저한 전투 테스트를 거쳐 사용하기에 안전하다고 느낄 때까지 알파 버전을 보류하려고 노력합니다. 일반적으로 모든 것은 Dev Preview 단계를 먼저 거친 다음 기술 미리보기 그런 다음 공개 릴리스로 나옵니다. 일반 가용성 (GA)는 이미 매우 안정적이어서 생산에 적합합니다.

왜 그런 겁니까? 다른 소프트웨어 개발과 마찬가지로 Kubernetes의 모든 초기 아이디어가 최종 릴리스에 도달하는 것은 아니기 때문입니다. 또는 목표에 도달하고 의도한 기능을 유지하지만 구현이 알파 버전의 구현과 근본적으로 다릅니다. 미션 크리티컬 워크로드를 지원하기 위해 OpenShift를 사용하는 수많은 Red Hat 고객과 함께 우리는 플랫폼의 안정성과 장기적인 지원에 특히 중점을 두고 있습니다.

Red Hat은 OpenShift를 자주 출시하고 함께 제공되는 Kubernetes 버전을 업데이트하기 위해 최선을 다하고 있습니다. 예를 들어, 이 글을 쓰는 시점의 OpenShift 4.3의 현재 GA 릴리스에는 Kubernetes 1.16이 포함되어 있습니다. 이는 Kubernetes 업스트림 버전 번호 1.17보다 한 단위만 뒤처지는 것입니다. 따라서 우리는 고객에게 엔터프라이즈급 Kubernetes를 제공하고 OpenShift의 새 버전을 출시함에 따라 추가적인 품질 관리를 제공하려고 노력하고 있습니다.

소프트웨어 수정: “우리가 프로덕션에 있는 Kubernetes 버전에 구멍이 있었습니다. 그리고 세 가지 버전을 업데이트해야만 닫을 수 있습니다. 아니면 어떤 옵션이 있나요?

Kubernetes 오픈 소스 프로젝트에서 소프트웨어 수정 사항은 일반적으로 다음 릴리스의 일부로 릴리스되며 때로는 이전 마일스톤 릴리스 하나 또는 두 개를 포함하여 6개월 정도의 범위를 제공합니다.

Red Hat은 다른 업체보다 먼저 중요한 수정 사항을 출시하고 훨씬 더 오랫동안 지원을 제공한다는 점에 자부심을 갖고 있습니다. Kubernetes 권한 상승 취약점(CVE-2018-1002105): 이는 Kubernetes 1.11에서 발견되었으며 이전 릴리스에 대한 수정 사항은 버전 1.10.11까지만 릴리스되었으므로 이 문제는 1.x에서 1.9까지 모든 이전 Kubernetes 릴리스의 구멍에 남겨졌습니다.

턴에서, Red Hat은 OpenShift를 버전 3.2로 다시 패치했습니다. (Kubernetes 1.2가 있음), XNUMX개의 OpenShift 릴리스를 캡처하고 고객에 대한 관심을 명확하게 보여줍니다(자세한 내용은 여기에).

OpenShift와 Red Hat이 Kubernetes를 발전시키는 방법

Red Hat은 Google에 이어 오픈소스 Kubernetes 프로젝트에 두 번째로 큰 소프트웨어 기여자이며, 가장 많은 성과를 내는 개발자 3명 중 5명이 Red Hat 출신입니다. 잘 알려지지 않은 또 다른 사실: 특히 Red Hat의 주도로 Kubernetes에 다음과 같은 많은 중요한 기능이 등장했습니다.

• RBAC. Kubernetes에는 Red Hat 엔지니어가 추가 OpenShift 기능이 아닌 플랫폼 자체의 일부로 RBAC 기능(ClusterRole, ClusterRoleBinding)을 구현하기로 결정하기 전까지는 RBAC 기능이 없었습니다. Red Hat은 Kubernetes 개선을 두려워합니까? 물론 그렇지 않습니다. 왜냐하면 Red Hat은 오픈 소스 원칙을 엄격하게 따르고 Open Core 게임을 플레이하지 않기 때문입니다. 독점 커뮤니티가 아닌 개발 커뮤니티가 주도하는 개선과 혁신은 더 실행 가능하고 더 널리 채택됩니다. 이는 오픈 소스 소프트웨어를 고객에게 더 유용하게 만들겠다는 우리의 핵심 목표와 잘 부합합니다.
• 포드에 대한 보안 정책(포드 보안 정책). 포드 내에서 애플리케이션을 안전하게 실행하는 이러한 개념은 원래 OpenShift에서 SCC(Security Context Constraints)라는 이름으로 구현되었습니다. 그리고 이전 예에서와 같이 Red Hat은 모든 사람이 사용할 수 있도록 이러한 개발을 오픈 쿠버네티스 프로젝트에 도입하기로 결정했습니다.

이 일련의 예시는 계속될 수 있지만 Red Hat이 Kubernetes를 개발하고 모두를 위해 더 나은 환경을 만들기 위해 진심으로 노력하고 있음을 보여주고 싶었습니다.

OpenShift가 Kubernetes라는 것은 분명합니다. 차이점은 무엇입니까? 🙂

지금까지 읽으면서 Kubernetes가 OpenShift의 핵심 구성 요소라는 것을 깨달았기를 바랍니다. 주요한 것이지만 유일한 것과는 거리가 멀습니다. 즉, 단순히 Kubernetes를 설치한다고 해서 엔터프라이즈급 플랫폼이 제공되는 것은 아닙니다. 인증, 네트워킹, 보안, 모니터링, 로그 관리 등을 추가해야 합니다. 또한 사용 가능한 수많은 도구 중에서 어려운 선택을 해야 합니다(생태계의 다양성을 이해하려면 한 번 살펴보세요). CNCF 차트) 어떻게든 일관성과 일관성을 보장하여 하나로 작동하도록 합니다. 또한 사용하는 구성 요소의 새 버전이 출시될 때마다 정기적으로 업데이트 및 회귀 테스트를 수행해야 합니다. 즉, 플랫폼 자체를 만들고 유지하는 것 외에도 이 모든 소프트웨어를 처리해야 합니다. 비즈니스 문제를 해결하고 경쟁 우위를 확보하는 데 시간이 많이 남지 않을 것 같습니다.

그러나 OpenShift의 경우 Red Hat은 이러한 모든 복잡성을 스스로 해결하고 Kubernetes 자체뿐만 아니라 Kubernetes를 실제 엔터프라이즈급으로 전환하는 데 필요한 전체 오픈 소스 도구 세트를 포함하는 기능적으로 완전한 플랫폼을 제공합니다. 즉각적이고 완벽하게 차분하게 프로덕션을 시작할 수 있는 솔루션입니다. 물론, 자체 기술 스택이 있는 경우 OpenShift를 기존 솔루션에 통합할 수 있습니다.

OpenShift는 스마트 Kubernetes 플랫폼입니다.

위의 그림을 살펴보십시오. Kubernetes 직사각형 외부에 있는 모든 것은 Red Hat이 Kubernetes가 설계상 갖고 있지 않은 기능을 추가하는 곳입니다. 이제 우리는 이러한 영역의 주요 부분을 살펴 보겠습니다.

1. 강력한 기반 OS: RHEL CoreOS 또는 RHEL

Red Hat은 20년 넘게 비즈니스 크리티컬 애플리케이션을 위한 Linux 배포판을 공급해 온 선두업체입니다. 이 분야에서 축적되고 지속적으로 업데이트되는 경험을 통해 우리는 컨테이너의 산업 운영을 위한 진정으로 신뢰할 수 있는 기반을 제공할 수 있습니다. RHEL CoreOS는 RHEL과 동일한 커널을 사용하지만 주로 컨테이너 실행 및 Kubernetes 클러스터 실행과 같은 작업에 최적화되어 있습니다. 크기가 줄어들고 불변성이 있으므로 클러스터 설정, 자동 크기 조정, 패치 배포 등이 더 쉬워집니다. 이러한 모든 기능을 통해 베어메탈부터 프라이빗 및 퍼블릭 클라우드까지 광범위한 컴퓨팅 환경에서 OpenShift를 통해 동일한 사용자 경험을 제공하기 위한 이상적인 기반입니다.

2. IT 운영 자동화

설치 프로세스 및 4일차 작업(즉, 일상적인 작업)의 자동화는 OpenShift의 장점으로, 최고 수준에서 컨테이너 플랫폼의 성능을 훨씬 쉽게 관리, 업데이트 및 유지 관리할 수 있습니다. 이는 OpenShift XNUMX 커널 수준에서 Kubernetes 운영자 지원을 통해 달성됩니다.

OpenShift 4는 또한 Red Hat 자체와 타사 파트너가 개발한 Kubernetes 운영자를 기반으로 하는 솔루션의 전체 에코시스템입니다(참조: 운영자 디렉토리 Red Hat 또는 운영 매장 Operatorhub.io, 타사 개발자를 위해 Red Hat에서 제작함).

통합 OpenShift 4 카탈로그에는 180개 이상의 Kubernetes 운영자가 포함되어 있습니다.

3. 개발자 도구

2011년부터 OpenShift는 개발자의 삶을 훨씬 쉽게 만들고, 코딩에 집중하도록 돕고, Java, Node.js와 같은 프로그래밍 언어에 대한 기본 지원을 제공하는 PaaS(Platform-as-a-Service) 플랫폼으로 제공되었습니다. , PHP, Ruby, Python, Go는 물론 CI/CD 지속적 통합 및 전달 서비스, 데이터베이스 등을 제공합니다. OpenShift 4는 다음을 제공합니다. 광범위한 카탈로그여기에는 Red Hat과 파트너가 개발한 Kubernetes 운영자를 기반으로 하는 100개 이상의 서비스가 포함되어 있습니다.

Kubernetes와 달리 OpenShift 4에는 전용 GUI(개발자 콘솔)는 개발자가 다양한 소스(git, 외부 레지스트리, Dockerfile 등)의 애플리케이션을 네임스페이스에 쉽게 배포하고 애플리케이션 구성 요소 간의 관계를 명확하게 시각화하는 데 도움이 됩니다.

개발자 콘솔은 애플리케이션 구성 요소에 대한 명확한 보기를 제공하고 Kubernetes 작업을 쉽게 만듭니다.

또한 OpenShift는 특히 다음과 같은 Codeready 개발 도구 세트를 제공합니다. 코드 레디 작업 공간는 OpenShift 위에서 직접 실행되고 IDE-as-a-service 접근 방식을 구현하는 웹 인터페이스를 갖춘 완전히 컨테이너화된 IDE입니다. 반면, 엄격하게 로컬 모드로 작업하려는 사람들을 위해 노트북에 배포할 수 있는 OpenShift 4의 모든 기능을 갖춘 버전인 Codeready Containers가 있습니다.

Kubernetes/OpenShift 플랫폼에서 효율적인 개발을 위한 서비스로서의 통합 IDE

OpenShift는 컨테이너화된 Jenkins 및 플러그인을 기반으로 즉시 전체 CI/CD 시스템을 제공합니다. DSL 파이프라인 또는 Kubernetes 지향 CI/CD 시스템 작업용 Tekton (현재 기술 미리보기 버전). 두 솔루션 모두 OpenShift 콘솔과 완벽하게 통합되어 파이프라인 트리거 실행, 배포, 로그 보기 등을 수행할 수 있습니다.

4. 적용 도구

OpenShift를 사용하면 기존의 상태 저장 애플리케이션과 마이크로서비스 또는 서버리스와 같은 새로운 아키텍처를 기반으로 하는 클라우드 기반 솔루션을 모두 배포할 수 있습니다. OpenShift Service Mesh 솔루션은 Istio, Kiali 및 Jaeger와 같은 마이크로서비스 유지 관리를 위한 주요 도구와 함께 즉시 사용 가능합니다. OpenShift Serverless 솔루션에는 Knative뿐만 아니라 OpenShift 플랫폼에서 Azure 기능을 제공하기 위해 Microsoft와의 공동 이니셔티브의 일부로 만들어진 Keda와 같은 도구도 포함되어 있습니다.

통합 솔루션 OpenShift ServiceMesh(Istio, Kiali, Jaeger)는 마이크로서비스 개발 시 유용합니다.

레거시 애플리케이션과 컨테이너 간의 격차를 해소하기 위해 OpenShift는 이제 컨테이너 네이티브 가상화(현재 TechPreview에 있음)를 사용하여 가상 머신을 OpenShift 플랫폼으로 마이그레이션하여 하이브리드 애플리케이션을 현실화하고 프라이빗 및 퍼블릭 클라우드 간 마이그레이션을 촉진합니다.

컨테이너 네이티브 가상화를 통해 OpenShift에서 실행되는 Windows 2019 가상 가상 머신(현재 기술 미리보기 버전)

5. 클러스터용 도구

모든 엔터프라이즈급 플랫폼에는 모니터링 및 중앙 집중식 로깅 서비스, 보안 메커니즘, 인증 및 권한 부여, 네트워크 관리 도구가 있어야 합니다. 그리고 OpenShift는 이 모든 것을 즉시 제공하며 ElasticSearch, Prometheus, Grafana와 같은 솔루션을 포함하여 모두 100% 오픈 소스입니다. 이러한 모든 솔루션에는 Red Hat의 광범위한 클러스터 모니터링 전문 지식을 사용하여 이미 구축 및 구성된 대시보드, 지표 및 경고가 함께 제공되므로 처음부터 프로덕션 환경을 효과적으로 제어하고 모니터링할 수 있습니다.

OpenShift는 또한 내장된 oauth 공급자를 통한 인증, LDAP, ActiveDirectory, OpenID Connect 등을 포함한 자격 증명 공급자와의 통합과 같이 기업 고객을 위한 중요한 기능을 표준으로 제공합니다.

OpenShift 클러스터 모니터링을 위해 사전 구성된 Grafana 대시보드

OpenShift 클러스터 모니터링을 위해 사전 구성된 150개 이상의 Prometheus 지표 및 경고

계속하기

솔루션의 풍부한 기능과 Red Hat의 쿠버네티스 분야에서의 광범위한 경험은 아래 그림에서 볼 수 있듯이 OpenShift가 시장에서 지배적인 위치를 차지한 이유입니다. 여기에).

“Red Hat은 현재 44%의 점유율로 시장을 선도하고 있습니다.
회사는 먼저 기업 개발자를 컨설팅하고 교육한 다음 기업이 컨테이너를 프로덕션에 배포하기 시작하면서 수익화로 전환하는 고객 중심 영업 전략의 이점을 누리고 있습니다.”

(출처 : www.lightreading.com/nfv/containers/ihs-red-hat-container-strategy-is-paying-off/d/d-id/753863)

이 기사가 즐거웠기를 바랍니다. 이 시리즈의 향후 게시물에서는 여기에서 논의된 각 범주에서 Kubernetes에 비해 OpenShift의 장점을 자세히 살펴보겠습니다.

출처 : habr.com