HCIP 연구 노트-클라우드 네이티브 기술-7

클라우드 네이티브의 개념과 배경

1.1 배경 - Enterprise IT Digital Transformation의 "3단계 및 2단계 변환"

• 서버 단계: 하드웨어 장비를 중심으로 하는 것이 특징이며, 다양한 제조업체의 장비 및 운영 체제 가상화 소프트웨어의 차별화에 따라 비즈니스 응용 프로그램을 사용자 정의하고 장비 설치, 디버깅, 응용 프로그램 배포, 운영 및 유지 관리는 기본적으로 인력에 의해 완료되며, 자동화 정도가 낮고 통합 장치 및 애플리케이션 관리 기능이 부족합니다. 이후 가상화 소프트웨어의 등장으로 리소스 활용률과 컨테이너 스케일링의 유연성은 어느 정도 개선됐지만 인프라와 소프트웨어의 분리, 복잡한 운영과 유지보수 문제를 근본적으로 해결하지는 못했다.
• 클라우드화 단계: 기존 모드의 분산 및 개별 장치를 통합하여 컴퓨팅 및 스토리지 네트워크와 같은 백업 리소스 풀링을 실현합니다.통합 가상화 소프트웨어 플랫폼을 통해 상위 계층 비즈니스 소프트웨어에 통합 리소스 관리 인터페이스를 제공하여 리소스를 실현합니다. 관리 기능의 자동화는 인프라 차이의 일부를 보호하고 응용 프로그램의 다양성을 향상시킵니다. 그러나 가상화 소프트웨어 플랫폼의 큰 차이, 특히 다양한 공급업체의 일부 상용 개선 사항으로 인해 공급업체 간에 기능을 공유할 수 없으며 응용 프로그램이 여전히 완전히 표준화된 모드로 구축할 수 없으며, 애플리케이션 배포는 여전히 리소스 중심적입니다.
• 클라우드 네이티브 단계: 이 단계에서 기업은 민첩한 애플리케이션 제공, 빠른 탄력성, 원활한 마이그레이션, 무손실 재해 복구 등을 포함하여 리소스 중심에서 애플리케이션 중심으로 초점을 전환합니다. 따라서 기업은 인프라 통합 방법을 고려하기 시작합니다. 비즈니스 플랫폼과 함께 비즈니스 애플리케이션을 위한 표준 운영, 모니터링 및 거버넌스 플랫폼을 제공하고 일반 비즈니스 기능을 플랫폼 측으로 싱크하여 기업이 애플리케이션 자동화를 보다 잘 실현할 수 있도록 지원합니다.

1.2 클라우드 네이티브란?

• 2015년에는 클라우드 네이티브 기반 CNCF가 설립되어 클라우드 네이티브가 기술 개념에서 오픈 소스 구현으로 전환되었습니다. CloudNative Computing Foundation은 2015년 7월 21일 Google, Huawei 및 기타 회사가 공동으로 설립했습니다. HUAWEI CLOUD는 Cloud Native Foundation(7CNCF)의 유일한 아시아 창립 멤버이자 중국의 유일한 플래티넘 멤버입니다.
• CNCF(Cloud Native Computing Foundation)는 클라우드 네이티브 기술을 촉진하기 위해 벤더 중립적인 오픈 소스 에코시스템을 육성하고 유지하는 데 전념하고 있습니다. 우리는 최첨단 모델을 대중화하여 대중이 이러한 혁신에 접근할 수 있도록 합니다.
• CNCF는 벤더 중립적인 오픈 소스 생태계를 육성하고 유지함으로써 클라우드 네이티브 기술의 광범위한 채택을 촉진하여 모든 곳에서 클라우드 네이티브를 구현한다는 비전을 실현하는 데 전념하고 있습니다. CNCF의 클라우드 네이티브 정의는 클라우드 네이티브의 개념을 보다 구체화하여 다양한 산업에서 클라우드 네이티브를 보다 쉽게 ​​이해할 수 있도록 하고, 클라우드 네이티브를 산업 전반에 폭넓게 적용할 수 있는 기반을 마련합니다. 지난 몇 년 동안 클라우드 네이티브 핵심 기술이 널리 채택되고 있습니다.CNCF 조사 보고서에 따르면 사용자의 80% 이상이 비즈니스 개발 및 배포를 위해 마이크로 서비스 아키텍처를 이미 사용했거나 사용할 계획이므로 사용자의 인식을 높입니다. 새로운 차원의 클라우드 네이티브 기술 사용 단계 기술 생태계도 빠르게 변화하고 있습니다.

1.3 클라우드 네이티브 개발

• 기본 컨테이너 엔진에서 시작하여 클라우드 네이티브 오픈 소스 프로젝트는 응용 분야를 지속적으로 확장하고 있으며 Edge 및 이기종과 같은 다양한 시나리오에 대한 적응 능력이 지속적으로 심화됩니다. 초기 오픈 소스 컨테이너 엔진 프로젝트 Docker부터 효율적인 컨테이너 오케스트레이션을 구현하는 Kubernetes, Swarm 및 Mesos에 이르기까지 마이크로 서비스 거버넌스 문제를 더 잘 해결하기 위해 Service Mesh 기술 기반의 Istio 및 Edge 시나리오를 위해 출시된 KubeEdge, K3s와 같은 프로젝트 (경량 Kubernetes 배포) 및 고성능 이기종 컴퓨팅 시나리오를 위한 Volcano는 모두 클라우드 네이티브와 산업의 통합을 가속화하고 다양한 산업의 혁신을 촉진하는 부스터가 되었습니다.
• 2020년에 중국정보통신학회는 클라우드 네이티브에 대한 심층 분석과 포괄적인 연구를 바탕으로 국내 클라우드 네이티브 산업의 발전 상태 및 동향과 결합하여 "2020년 클라우드 네이티브 개발 백서"를 편찬했습니다. 2020년 HUAWEI CLOUD는 Cloud Native 2.0 개념을 업계에 처음으로 제안했으며 Cloud Native 2.0을 통해 모든 기업이 "새로운 클라우드 네이티브 기업"이 되기를 희망합니다.

1.4 클라우드 네이티브 2.0

• 기업 디지털 트랜스포메이션의 초기 단계는 주로 오프라인에서 클라우드로 비즈니스를 이전하는 단계이며, 이 단계에서 기업은 주로 클라우드에서 비즈니스를 배포하고 실행하는 ON CLOUD라고 할 수 있습니다. 이 형태에서는 리소스 풀의 클라우드화를 통해 IDC 시대의 운영 및 유지 보수, 배포 및 확장 문제가 해결되었지만 기존의 단일 애플리케이션 아키텍처와 Chimney 아키텍처가 가져온 일련의 애플리케이션 수준 문제는 그러나 비즈니스에 대한 클라우드의 가치는 여전히 주로 리소스 공급 단계에 있으며 클라우드의 가치를 충분히 활용할 수 없습니다.
• 클라우드 네이티브 1.0 시대에 클라우드 네이티브 기술은 단일 아키텍처와 자원 중심 접근 방식으로 인프라 계층에 집중되었으며 지원되는 응용 프로그램 생태는 비교적 단순했으며 주로 인터넷 산업에 적용되었습니다.
• 기업의 디지털 변혁이 심화됨에 따라 기업은 클라우드 컴퓨팅이 가져다주는 배당금을 충분히 향유해야 하며, 현재의 ON CLOUD에서 IN CLOUD로 비즈니스 역량을 클라우드에서 태어나 클라우드보다 더 오래 성장시킬 필요가 있습니다. , 새로운 클라우드 기반 기능과 기존 기능을 유기적으로 조정하고 끊김 없이 서 있습니다. Born in the cloud는 클라우드 네이티브 기술, 아키텍처 및 서비스를 기반으로 엔터프라이즈 애플리케이션을 구축하는 것을 의미하고 클라우드에서 성장하는 것은 클라우드의 이점을 최대한 활용하여 엔터프라이즈 애플리케이션 및 비즈니스 개발을 지원하여 디지털 구축을 가져오는 것을 의미합니다. 기업과 비즈니스 인텔리전스를 새로운 단계로 업그레이드 우리는 지금을 클라우드 네이티브 2.0 시대라고 부릅니다.
• 클라우드 네이티브 2.0, "온클라우드"에서 "인클라우드"로의 엔터프라이즈 클라우드화, 클라우드에서 태어나 클라우드에서 성장하고 깨지지 않고 구축 기업의 새로운 역량은 클라우드 네이티브를 기반으로 구축되어 클라우드에서 태어나 애플리케이션, 데이터, AI의 전 생애 주기가 클라우드에서 완성되어 클라우드보다 길어짐과 동시에 기존의 역량이 끊기지 않고 유기적으로 계승됨 "새로운 클라우드 네이티브 기업"을 지원하는 새로운 인텔리전스 단계로 업그레이드하기 위한 새로운 기능과 조정됩니다. 클라우드 네이티브 2.0은 기업입니다
• 지능형 업그레이드의 새로운 단계에서 엔터프라이즈 클라우드화는 "ON Cloud"에서 "IN Cloud"로 이동하여 "새로운 클라우드 네이티브 엔터프라이즈"가 되고 있습니다. 새로운 기능과 기존 기능을 해체 없이 구축하고 유기적으로 조율하여 리소스 효율성, 애플리케이션 민첩성, 비즈니스 인텔리전스, 보안 및 신뢰성을 달성할 수 있습니다.

1.5 클라우드 네이티브 2.0의 장점

• 클라우드 네이티브 2.0 시대:
  • 클라우드 네이티브 기술은 리소스 중심에서 애플리케이션 중심으로 전환해야 하며, 클라우드 네이티브 인프라는 애플리케이션 특성을 인지할 수 있어야 하며, 애플리케이션은 클라우드 네이티브 인프라를 보다 지능적이고 효율적으로 사용할 수 있어야 합니다.
  • 클라우드 네이티브 멀티클라우드 아키텍처를 기반으로 클라우드 네이티브 애플리케이션의 분산 추세를 지원하고 디바이스-엣지-클라우드 협업 및 멀티 클라우드 협업을 지원하며 정부 및 기업을 위한 복잡한 전체 시나리오 애플리케이션을 지원합니다.
  • Cloud Native 2.0은 새로운 기능과 기존 기능이 유기적으로 조정되고 확립되지만 깨지지 않는 개방형 시스템입니다.
  • 클라우드 네이티브 2.0은 애플리케이션, 빅 데이터, 데이터베이스 및 AI와 같은 풀 스택 기술로 확장되는 풀 스택 기능입니다.

1.6 클라우드 네이티브 2.0의 10가지 아키텍처 모델

1.7 HUAWEI CLOUD 클라우드 네이티브 2.0 아키텍처 파노라마

• 클라우드 네이티브 하드웨어 계층: 클라우드 인프라 서비스 인식 하드웨어 PCI 보드(SDI/Qingtian 오프로드), 자체 개발 범용 CPU(Peng) 도입을 통해 클라우드 컴퓨팅 성능의 궁극적인 비용 효율성 추구를 목표로 합니다. , 이기종 NPU(Yiteng)는 동종 및 이기종 컴퓨팅을 위한 일련의 하드웨어 오프로딩과 심도 있는 소프트웨어 및 하드웨어 협업을 통해 컨테이너 및 가상 머신 런타임과 함께 작동하는 가장 비용 효율적인 컴퓨팅 플랫폼을 만듭니다.
• 클라우드 네이티브 OS: 표준 운영 체제 기능 외에도 클라우드 컨텍스트에서 이 계층의 책임은 "리소스를 크고 작은 것으로 분할"하여 물리적 서버 리소스를 여러 가상 머신과 여러 컨테이너로 나누는 것입니다. 리소스 스케줄링 지원 제공 하드웨어 패스스루를 통해 스토리지 및 네트워크 가상화 성능 오버헤드를 최소화합니다.
• 클라우드 네이티브 탄력적 리소스 레이어: 클라우드 컨텍스트에서 이 레이어의 책임은 클라우드 네이티브 컴퓨팅, 특히 K8S 컨테이너 클러스터 및 해당 확장 작업, Yaoguang 지능형 스케줄링 시스템과 같은 소규모에서 대규모 프로세스입니다. 클라우드 에지와 지역 간 글로벌 스케줄링, 클라우드 네이티브 네트워크 가상화 기능, 클라우드 네이티브 분산 스토리지 및 재해 복구 및 높은 안정성과 같은 고급 스토리지를 연결합니다.
• 클라우드 네이티브 애플리케이션 및 데이터 구현 계층: 클라우드 네이티브 분산 미들웨어, 블록체인, 클라우드 네이티브 에지, 클라우드 보안 지원, 클라우드 네이티브 데이터베이스 및 클라우드 네이티브 빅 데이터, AI ModelArts Pratt & Whitney AI 개발 플랫폼, 클라우드 네이티브 비디오 및 클라우드 네이티브 IOT 사물 인터넷.
• 클라우드 네이티브 애플리케이션 수명 주기: DevSecOPS 파이프라인, 클라우드 네이티브 서비스 거버넌스 및 오케스트레이션, 테넌트가 자신의 비즈니스를 배포하기 위한 CMDB, 모니터링 및 운영 및 유지 관리 서비스 등을 포함합니다.
• 클라우드 네이티브 멀티 테넌시 프레임워크: 클라우드 서비스에 대한 멀티 테넌트 인증 및 권한 관리(클라우드 서비스 및 클라우드 리소스 기능 액세스를 위한 ID 인증, 클라우드 서비스 개체 인스턴스에 대한 액세스 권한 관리), 클라우드 네이티브 운영 및 청구, 클라우드 서비스 Open API 기능(클라우드 서비스 소비 인터페이스 진입), 클라우드 네이티브 콘솔(클라우드 서비스 소비 인터페이스 진입) 등

오픈 소스 컨테이너 기술 소개

2.1 컨테이너 기술이란?

• Docker는 서로 다른 시스템 간에 컨테이너를 이식할 수 있도록 만든 최초의 시스템입니다. 애플리케이션 패키징 프로세스를 단순화할 뿐만 아니라 패키징된 애플리케이션의 라이브러리 및 종속성을 단순화하고 전체 운영 체제의 파일 시스템도 간단한 이식 가능한 패키지로 패키징할 수 있으며 Docker를 실행하는 다른 시스템에서 사용할 수 있습니다. 업계에서 컨테이너 기술을 사용한다는 정의는 Docker로 대표되는 컨테이너 엔진 기술과 K8S 기반의 컨테이너 오케스트레이션 기술이며, 그 외 Kata 보안 컨테이너와 같은 OCI 표준을 따르거나 호환되는 컨테이너 기술이 많습니다.
• 가상 머신을 사용할 때와 비교할 때 컨테이너는 다음과 같은 이점이 있습니다.
  • 시스템 리소스의 보다 효율적인 사용: 컨테이너는 하드웨어 가상화 및 전체 운영 체제 실행과 같은 오버헤드가 필요하지 않기 때문에 컨테이너의 시스템 리소스 활용률이 더 높습니다. 애플리케이션 실행 속도, 메모리 손실 등을 포함합니다.
  • 빠른 시작 시간: 기존 가상 머신 기술은 애플리케이션 서비스를 시작하는 데 몇 분 정도 걸리는 반면 Docker 컨테이너 애플리케이션은 호스트 커널에서 직접 실행되기 때문에 전체 운영 체제를 시작할 필요가 없으므로 몇 초 안에 시작할 수 있습니다. 밀리초 시간
  • 일관된 런타임 환경: 개발 프로세스의 일반적인 문제는 환경 일관성 문제입니다. 개발 환경과 테스트 환경, 프로덕션 환경 간의 불일치로 인해 개발 과정에서 몇 가지 문제가 발견되지 않았습니다. Docker 이미지는 커널을 제외한 완전한 런타임 환경을 제공하여 애플리케이션 런타임 환경의 일관성을 보장합니다.
  • 더 쉬운 마이그레이션: Docker는 실행 환경의 일관성을 보장하므로 애플리케이션 마이그레이션이 더 쉬워집니다. 그리고 물리적 머신이든 가상 머신이든 많은 플랫폼에서 실행될 수 있으며 실행 결과는 일관적입니다.
  • 손쉬운 유지 관리 및 확장: Docker에서 사용하는 계층화된 스토리지 및 미러링 기술을 사용하면 애플리케이션의 반복 부분을 더 쉽게 재사용할 수 있으며 애플리케이션의 유지 관리 및 업데이트도 더 쉬워집니다. 또한 Docker 팀은 다양한 오픈 소스 프로젝트 팀과 함께 많은 수의 고품질 공식 이미지를 유지 관리하며 프로덕션 환경에서 직접 사용할 수 있을 뿐만 아니라 추가 사용자 정의를 위한 기반으로 사용할 수 있으므로 크게 애플리케이션 서비스를 위한 이미지 제작 비용을 절감합니다.

2.2 핵심기술 소개

• Docker가 사용하는 몇 가지 핵심 기술은 Docker가 발명한 것이 아니라 Linux의 성숙한 기술이며 Docker는 이러한 기술을 통합하여 혁신적인 결과를 얻었습니다.
• 그 중 Namespace는 운영 환경의 격리를 담당합니다. 즉, 각 컨테이너는 독립적인 프로세스이며 네임스페이스 기술을 통해 격리됩니다.
• Cqgroup은 실행 중인 리소스의 격리 또는 독점을 담당하며 서로를 침해하지 않고 각 컨테이너에 대한 리소스 수를 지정할 수 있습니다. 각 컨테이너는 프로세스 격리, 네트워크 격리 및 파일 격리를 포함하여 서로에게 보이지 않습니다.
• 유니온 파일 시스템은 애플리케이션 작업의 소형화를 위한 통합 표준입니다.컨테이너 이미지는 컨테이너 작업의 기반을 제공하지만 컨테이너 이미지는 컨테이너와 같지 않습니다. 컨테이너 이미지는 스토리지 기반 기술을 통해 관리됩니다. 일련의 계층화된 읽기 전용 파일이며 컨테이너 이미지가 컨테이너로 실행되면 이미지의 최상위 계층, 즉 컨테이너 계층에 쓰기 가능한 계층이 추가됩니다.런타임 컨테이너에 대한 모든 수정 사항은 실제로 읽혀집니다. 쓰기 계층의 수정, 새 파일 작성 및 기존 파일 수정과 같은 컨테이너에 대한 모든 변경 사항은 이 컨테이너 계층에만 적용됩니다.
• 컨테이너는 운영 체제 커널의 내장 기능이므로 이를 기반으로 가상화 및 새 커널을 실행할 필요가 없으며 본질적으로 프로세스 수준 격리이므로 더 가볍고 배포, 운영 손실 유지 보수 및 성능도 낮습니다. 동시에 컨테이너는 응용 프로그램 및 운영 환경과 함께 패키징되기 때문에 이식성이 우수하고 표준화 수준이 높아 응용 프로그램의 대규모 유연한 확장 및 관리를 위한 좋은 기반을 제공합니다.
• Dockerd는 docker 데몬이라고 하는 docker 아키텍처의 백그라운드에 상주하는 시스템 프로세스입니다.
• Containerd는 dockerd와 runc 사이의 중간 통신 구성 요소로 Docker의 컨테이너 관리 및 운영은 기본적으로 containerd를 통해 완료됩니다.
• Containerd-shim은 실제로 컨테이너를 운영하는 캐리어로, 컨테이너가 시작될 때마다 새로운 containerd-shim 프로세스가 시작됩니다.
• RunC는 OCI 표준 형식으로 응용 프로그램을 실행하기 위한 명령줄 도구입니다.

2.3 Kata 컨테이너 소개

• Kata 컨테이너는 Intel, Huawei, Red Hat과 같은 회사에서 시작한 오픈 소스 컨테이너 프로젝트입니다.베어 메탈에서 직접 컨테이너 관리 도구를 실행하고 워크로드의 강력한 보안 격리를 달성할 수 있는 기능을 제공합니다.가상 머신의 보안 이점을 결합합니다. 컨테이너의 속도와 관리 용이성 완벽한 통합.

2.4 Docker 컨테이너의 일반적인 사용 프로세스

2.5 쿠버네티스

• Kubernetes라는 단어는 그리스어에서 유래했으며 조타수 또는 항해사를 의미합니다. K에서 s까지 8글자이므로 k8s라고도 합니다. 쿠버네티스는 구글이 오픈소스 커뮤니티에 기여한 제품으로 자체 비즈니스 속성을 제거한 후 자체 내부 컨테이너 보그(뻐꾸기)를 기반으로 한 오픈소스 제품이다. 쿠버네티스는 컨테이너 오케스트레이션 분야에서 업계에서 인정하는 사실상의 표준으로, 거의 모든 퍼블릭 클라우드 벤더의 컨테이너 기술은 쿠버네티스를 기반으로 구현된다.
• K8s의 표준 아키텍처는 클러스터를 기반으로 합니다.클러스터는 완전한 K8s 제품 세트입니다.대부분의 기업에서 K8s의 표준 아키텍처는 클러스터를 기반으로 하며 클러스터 수준 관리를 위해 관리 평면이 캡슐화됩니다.
• 애플리케이션 개발자에게 Kubernetes는 클러스터 운영 체제로 간주될 수 있습니다. 쿠버네티스는 서비스 검색, 확장, 로드 밸런싱, 자가 치유, 선택과 같은 기능을 제공하여 개발자가 인프라 관련 구성에서 벗어나도록 합니다.
• 기술적 특성에 따라 다음과 같은 장점이 있습니다: 정의된 애플리케이션 상태에 따라 자동 배포, 재시작, 마이그레이션 및 확장, 플러그인 메커니즘을 통해 K8S는 다양한 인프라(퍼블릭 클라우드, 프라이빗 클라우드)와 호환됩니다. 격리 메커니즘은 다양한 서비스를 신속하게 제공할 수 있습니다. 팀은 운영 환경을 구축합니다.
• 클러스터에는 전체 컨테이너 클러스터 관리를 담당하는 마스터 제어 노드 마스터가 있을 것입니다. 일반적으로 etcd 고가용성 시나리오에서 사용되는 마스터 수는 최소 3개입니다. 클러스터에는 컨테이너 애플리케이션 실행을 담당하는 많은 비즈니스 노드 노드가 있습니다. 마스터는 노드 관리를 위한 에이전트로 각 노드에 kubelet을 설치합니다.

2.5.1 쿠버네티스 클러스터 아키텍처 소개

• 마스터 노드:
  • API 서버: 외부 요청을 수락하고 ETCD에 정보를 기록하면서 구성 요소가 서로 통신하는 전송 스테이션
  • 컨트롤러 관리자: 구성 요소 복제, 노드 노드 추적, 노드 장애 처리 등과 같은 클러스터 수준 기능을 수행합니다.
  • 스케줄러: 애플리케이션 스케줄링을 담당하는 구성 요소로, 다양한 조건(예: 사용 가능한 리소스, 노드 선호도 등)에 따라 컨테이너가 노드에서 실행되도록 스케줄링합니다.
  • Etcd: 클러스터에 있는 개체의 모든 네트워크 구성 및 상태 정보를 저장하는 데 사용되는 분산 데이터 저장소 구성 요소입니다.
• 노드 노드:
  • Kubelet: Kubelet은 주로 컨테이너 런타임을 처리하고 API 서버와 상호 작용하여 노드에서 컨테이너를 관리합니다. cAdvisor를 통한 Node 머신의 리소스 및 컨테이너에 대한 실시간 모니터링 및 성능 데이터 수집
  • Kube-proxy: 노드에서 애플리케이션의 액세스 문제를 해결하기 위한 애플리케이션 구성 요소 간의 액세스 프록시
  • 컨테이너 런타임: Docker, containerd, CRI-O 및 Kubernetes CRI와 같은 컨테이너 실행을 담당하는 소프트웨어입니다.
• Kubectl은 Kubernetes 클러스터용 명령줄 도구로, kubectl 명령을 통해 모든 머신에 kubectl을 설치하고 Kubernetes 클러스터를 작동할 수 있습니다.
• K8s를 사용할 때 사용자는 Master의 apiserver를 사용하여 선언적 인터페이스에 정의된 필수 응용 서비스 및 기타 리소스 개체를 호출합니다.마스터의 컨트롤러 및 스케줄러는 사용자 정의에 따라 Node에 생성되어 모니터링됩니다. 상태는 항상 사용자의 정의를 준수하도록 보장됩니다. 노드의 컨테이너 애플리케이션은 kube-proxy를 통해 "시스템" 액세스 기능을 제공합니다.

2.5.2 리소스 관리 - 파드

• 쿠버네티스 오케스트레이션의 최소 단위는 컨테이너가 아니라 파드(Pod)라는 것입니다. 중국어로 Pod는 Pea Ying을 의미하며, 1마일에 많은 완두콩이 있을 수 있으며, 이 완두콩은 하나씩 컨테이너 인스턴스입니다.
• 대부분의 경우 컨테이너를 사용하여 마이크로서비스를 호스팅해야 합니다(마이크로서비스란 간단히 말해서 작고 단일한 서비스입니다). 마이크로서비스 설계를 할 때 일반적으로 하나의 애플리케이션에 하나의 프로세스가 있는 것을 권장하며, 캐리어가 컨테이너라면 하나의 컨테이너와 하나의 프로세스입니다. 하지만 마이크로서비스를 관리하기 위해서는 관련 서비스 모니터링 소프트웨어나 데이터 판독 소프트웨어를 설치해야 하는 경우가 많은 것이 현실입니다. 즉, 하나의 컨테이너에 여러 소프트웨어, 즉 여러 프로세스를 설치해야 합니다. 이것은 우리가 방금 말한 하나의 컨테이너, 하나의 프로세스의 원칙을 깨뜨립니다. 마이크로서비스의 설계 원칙에 부합하기 위해 Pod의 개념을 설계했습니다. 일반적으로 Pod에는 여러 개의 컨테이너가 있고 하나의 서비스 컨테이너(서비스 제공용)와 여러 개의 보조 컨테이너(서비스 컨테이너 모니터링 또는 데이터 관리 완료)가 있습니다. 포드에서 각각: 웹 컨테이너, 모니터링 컨테이너 및 로그 읽기 컨테이너. 먼저 웹 컨테이너에서 웹 소프트웨어만 실행되며 노출된 포트는 80입니다. 모니터링 컨테이너에서 웹 컨테이너를 실행하는 모니터링 소프트웨어는 127.0.0.1:80만 모니터링하면 웹 서비스 모니터링이 완료됩니다. Pod 내의 컨테이너는 IP 주소를 공유하기 때문입니다. 로그 읽기 컨테이너는 ROD의 컨테이너가 데이터 저장소를 공유하므로 해당 로그 관리 플랫폼에 해당 경로의 파일 읽기만 보고하면 됩니다.
• 컨테이너 런타임 인터페이스(Container Runtime Interface)는 CRI라고 합니다. CRI는 컨테이너와 미러의 서비스 인터페이스를 정의합니다. 컨테이너 런타임과 미러의 수명 주기가 서로 격리되어 두 가지 서비스를 정의해야 하기 때문입니다. CRI는 kubelet과 컨테이너 런타임 간의 통신을 위한 기본 프로토콜입니다.

2.5.3 자원 탐지

• 프로브 유형:
  • Liveness Probe: 컨테이너가 실행 중인지 여부를 나타냅니다. 활동성 프로브가 실패하면 kubelet이 컨테이너를 종료하고 컨테이너는 다시 시작 정책에 따라 결정됩니다.
  • 준비 상태 프로브: 컨테이너가 요청을 처리할 준비가 되었는지 여부입니다. 준비 프로브가 실패하면 엔드포인트 컨트롤러는 포드와 일치하는 모든 서비스의 엔드포인트 목록에서 포드의 IP 주소를 제거합니다.
  • 시작 프로브: 컨테이너의 애플리케이션이 시작되었는지 여부. 시작 프로브가 제공되면 이 프로브가 성공할 때까지 다른 프로브가 비활성화됩니다. 시작 프로브가 실패하면 kubelet이 컨테이너를 종료하고 컨테이너는 다시 시작 정책에 따라 다시 시작됩니다.
• DaemonSet의 몇 가지 일반적인 용도
  • 각 노드에서 클러스터 데몬을 실행합니다.
  • 각 노드에서 로그 수집 데몬을 실행합니다.
  • 각 노드에서 모니터링 데몬 실행
• Kubernetes는 노드 및 Pod 수준에서 선호도 및 반선호도를 지원합니다. 선호도 및 반선호도 규칙을 구성함으로써 사용자는 포그라운드 포드 및 백그라운드 포드를 함께 배포, 특정 유형의 애플리케이션을 특정 특정 노드에 배포, 다른 애플리케이션을 다른 노드에 배포 등과 같은 엄격한 제한 또는 기본 설정을 지정할 수 있습니다.

2.5.4 자원 스케줄링

• 쿠버네티스는 포드를 관리하기 위한 컨트롤러(controller)를 제공하며, 컨트롤러는 여러 개의 포드를 생성하고 관리할 수 있으며 복사 관리, 롤링 업그레이드, 자가 치유 기능을 제공합니다.
• Deployment: 현재 가장 많이 사용되는 컨트롤러는 Deployment이며, Deployment가 생성되면 자동으로 ReplicaSet이 생성된다. Deployment는 하나 이상의 RS,w를 관리하고 RS를 통해 Pod를 관리할 수 있습니다.
• 배포 컨트롤러 아래의 포드에는 공통 기능이 있습니다. 즉, 각 포드는 이름과 IP 주소를 제외하고 동일합니다. 필요한 경우 Deployment는 Pod 템플릿을 통해 새 Pod를 생성할 수 있으며, 필요하지 않은 경우 Deployment는 임의의 Pod를 삭제할 수 있습니다. 일반적으로: Pod에는 하나의 컨테이너 또는 특히 밀접하게 관련된 여러 컨테이너가 포함됩니다. ReplicaSet에는 하나 이상의 동일한 Bod가 포함됩니다. 배포에는 하나 이상의 서로 다른 ReplicaSet가 포함됩니다.
• 쿠버네티스는 이 문제를 해결하기 위해 StatefulSet을 제공하는데, StatefulSet은 각 Pod에 대해 고정된 이름을 제공하고 Pod 이름에는 0-N의 고정 접미사가 추가되며, Pod가 다시 예약된 후에도 Pod 이름과 HostName은 변경되지 않습니다. . Headless Service를 통해 각 Pod에 고정 액세스 도메인 이름 서비스를 제공하는 StatefulSet의 개념은 이후 장에서 자세히 소개됩니다. StatefulSet는 고정 식별자로 PVC를 생성하여 일정을 변경한 후에도 hw35802903Pod가 동일한 영구 데이터에 계속 액세스할 수 있도록 합니다.
• Job 및 CronJob은 단기 일회성 작업, 즉 한 번만 실행되는 작업을 일괄 처리하고 일괄 작업의 하나 이상의 포드가 성공적으로 종료되도록 보장합니다.
  • 작업: Kubernetes에서 일괄 작업을 제어하는 ​​데 사용하는 리소스 객체입니다. 배치 처리 비즈니스와 장기 서보 비즈니스(Deployment, Statefulset)의 주요 차이점은 배치 처리 비즈니스는 처음부터 끝까지 실행되는 반면 장기 서보 비즈니스는 사용자가 멈추지 않고 영원히 실행된다는 것입니다. Job이 관리하는 Pod는 사용자 설정에 따라 작업이 성공적으로 완료되면 자동으로 종료됩니다.
  • CronJob: Linux 시스템의 crontab 파일에 있는 한 줄과 유사한 시간 기반 작업으로 지정된 시간에 지정된 작업을 실행합니다.

2.5.5 리소스 구성

• Secret은 키-값 쌍의 형태로 데이터를 저장한다는 점에서 ConfigMap과 동일하지만 Secret 생성 시 Secret의 Value는 Base64 인코딩을 사용해야 한다는 차이점이 있습니다.
• 비밀:
  • 포드를 생성하고 보고 편집하는 과정에서 Secret 노출 위험이 적습니다.
  • 시스템은 가능한 경우 비밀 개체를 디스크에 쓰지 않는 등의 추가 예방 조치를 취합니다.
  • Pod에서 요청한 Secret만 해당 컨테이너에서 볼 수 있으며 한 Pod는 다른 Pod의 Secret에 액세스할 수 없습니다.

2.5.6 쿠버네티스 네트워크

• 특정 구현과 관련된 서로 다른 노드 간에 브리지를 연결하는 방법에는 여러 가지가 있습니다. 그러나 클러스터에는 포드 주소가 고유해야 하므로 노드 간 브리지는 일반적으로 포드 IP 주소가 중복되지 않도록 다른 주소 세그먼트를 사용합니다.
• 포드 내의 컨테이너 간 통신: 포드 내의 컨테이너는 일반적으로 인프라 컨테이너에서 제공하는 동일한 네트워크 네임스페이스를 공유합니다. 동일한 Pod에서 실행되는 모든 컨테이너는 동일한 호스트의 여러 프로세스와 유사하며 루프백 인터페이스를 통해 서로 상호 작용할 수 있습니다. Pod마다 고유한 IP 주소가 있기 때문에 서로 다른 Pod 간에 포트 충돌 문제가 없습니다.
• 클러스터의 다른 포드 및 노드는 네트워크 주소 변환, 터널링 또는 프록시 없이 IP를 통해 포드와 직접 통신할 수 있습니다. Pod 내부와 외부에서 동일한 iP가 사용되므로 DNS와 같은 표준 이름 지정 서비스 및 검색 메커니즘을 직접 사용할 수 있습니다. 이러한 통신 모델의 통신 요구 사항은 K8s 네트워크 플러그인이 해결해야 하는 문제이기도 합니다. 구현 방법에는 중첩 네트워크 모델과 라우팅 네트워크 모델 등이 포함됩니다. 곧.
• 포드 간 통신: 포드는 IP 주소를 통해 직접 통신할 수 있지만 전제는 포드가 서로의 IP를 알아야 한다는 것입니다. 클러스터에서 Pod는 자주 파괴되고 생성될 수 있으며 이는 Pod의 IP가 고정되어 있지 않음을 의미합니다. Pod의 IF가 고정되지 않는 문제를 해결하기 위해 sefice는 Pod에 액세스하기 위한 추상화 계층을 제공합니다. 백엔드 Pod가 어떻게 변경되더라도 서비스는 안정적인 프런트엔드로 외부 서비스를 제공합니다. 동시에 Service는 고가용성 및 로드 밸런싱 기능도 제공하며 Service는 올바른 Pod로 요청을 전달하는 역할을 합니다.
• Flannel은 쿠버네티스를 위해 CoreOS 팀이 설계한 네트워크 계획 서비스로, 간단히 말해서 클러스터의 다른 노드 호스트에서 생성한 컨테이너가 전체 클러스터에 대해 고유한 가상 IP 주소를 갖도록 하는 기능입니다.
• Flannel의 단순함에 비해 Calico는 성능과 유연성으로 유명합니다. Calico의 기능은 보다 포괄적이며 호스트와 포드 간의 네트워크 연결을 제공할 뿐만 아니라 네트워크 보안 및 관리도 포함합니다.

2.5.7 쿠버네티스 네트워크 - 서비스

• 포드가 생성된 후 포드에 직접 액세스하면 다음과 같은 문제가 발생합니다.
  • 포드는 언제든지 배포와 같은 컨트롤러에 의해 삭제 및 재구축되며 포드 액세스 결과는 예측할 수 없게 됩니다.
  • Pod의 IP 주소는 Pod가 시작된 후에 할당되며 Pod의 IP 주소는 시작되기 전에는 알 수 없습니다.
  • 애플리케이션은 종종 동일한 이미지를 실행하는 여러 포드로 구성되며 포드에 하나씩 액세스하는 것은 비현실적입니다.
• RC, RS, Deployment는 서비스를 지원하는 마이크로서비스 Pod의 수만 보장할 뿐 이러한 서비스에 액세스하는 방법의 문제는 해결하지 못합니다. Pod는 실행 중인 서비스의 인스턴스일 뿐이며 언제든지 한 노드에서 중지하고 다른 노드에서 새 IP로 새 Pod를 시작할 수 있으므로 특정 IP 및 포트 번호로 서비스를 제공할 수 없습니다. 서비스를 안정적으로 제공하기 위해서는 서비스 탐색 및 로드 밸런싱 기능이 필요합니다. 서비스 검색 작업은 클라이언트가 액세스하는 서비스에 해당하는 백엔드 서비스 인스턴스를 찾는 것입니다. K8s 클러스터에서 클라이언트가 액세스해야 하는 서비스는 Service 개체입니다. 각 서비스는 클러스터 내의 유효한 가상 IP에 해당하며, 클러스터는 가상 IP를 통해 서비스에 접근합니다.
• 쿠버네티스 서비스는 추상화를 정의합니다. 즉, 포드의 논리적 집합과 이러한 포드에 액세스할 수 있는 정책(종종 마이크로서비스라고 함)입니다. 이 포드 세트는 일반적으로 LabelSelector를 통해 서비스에서 액세스할 수 있습니다.
• 서비스 구현 유형은 주로 다음과 같습니다.
  • ClusterIP: Pod 액세스를 위해 클러스터 내부에 가상 IP 주소를 제공합니다(기본 모드).
  • NodePort: 외부 액세스를 위해 Node에서 go 포트 열기
  • LoadBalancer: 외부 로드 밸런서를 통해 액세스합니다.

2.5.8 쿠버네티스 네트워크 - 인그레스

• Ingress는 부하 분산, SSL 종료 및 이름 기반 가상 호스팅을 제공할 수 있습니다. Ingress는 클러스터 외부에서 클러스터 내의 서비스로 HTTP 및 HTTPS 경로를 노출합니다. 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 제어됩니다.
• Ingress 기능을 사용하려면 Kubernetes 클러스터에 Ingress 컨트롤러가 설치되어 있어야 합니다. IngressController에는 많은 구현이 있으며, 가장 일반적인 것은 Kubernetes에서 공식적으로 유지 관리하는 NGINX IngressController입니다. 일반적으로 여러 벤더가 자체 구현을 가지고 있습니다. 예를 들어 Huawei Cloud CCE는 Huawei Cloud Elastic Load Balancing Service ELB를 사용하여 Ingress Layer 7 로드 밸런싱을 구현합니다.

2.5.9 영구 저장

• 볼륨의 수명 주기는 이를 마운트한 파드의 수명 주기와 동일하지만, 볼륨의 종류에 따라 볼륨이 사라진 후에도 볼륨 내부에 파일이 존재할 수 있다. Pod의 모든 컨테이너는 볼륨에 액세스할 수 있지만 마운트해야 하며 컨테이너의 모든 디렉터리에 마운트할 수 있습니다.
  • PV: NFS 마운트 디렉토리와 같이 호스트 시스템에 지속적으로 저장되는 디렉토리를 주로 정의하는 영구 스토리지 볼륨입니다.
  • PVC: 볼륨 스토리지의 크기, 읽기 및 쓰기 권한 등과 같이 Pod가 사용하려는 영구 스토리지의 속성입니다.
• PV 및 PVC 방법이 기본 스토리지를 보호할 수 있지만 PV 생성은 더 복잡하며 일반적으로 클러스터 관리자가 관리합니다. Kubernetes가 이 문제를 해결하는 방법은 PV를 자동으로 생성할 수 있는 PV를 동적으로 구성하는 방법을 제공하는 것입니다. 관리자는 PV 프로비저너(provisioner)를 배포한 후 해당 StorageClass를 정의하여 개발자가 PVC를 생성할 때 생성할 스토리지 유형을 선택할 수 있습니다.PVC는 StorageClass를 PV 프로비저너로 전달하고 프로비저너는 자동으로 PV를 생성합니다.
• StorageClass는 클러스터의 스토리지 유형 "분류"를 설명하며 PVC/PV를 생성할 때 StorageClass를 지정해야 합니다.
• 쿠버네티스 관리자는 네트워크 스토리지의 유형을 설정하고 해당 PV 디스크립터 구성을 쿠버네티스에 제공합니다.사용자는 스토리지가 필요할 때 PVC를 생성한 다음 PVC를 포드의 볼륨과 연결하기만 하면 포드가 스토리지 리소스를 사용합니다.

2.6 로컬 K8S 클러스터의 클라우드 마이그레이션 프로세스 소개

• 클러스터 마이그레이션에는 대략 다음 6단계가 포함됩니다.
  • 대상 클러스터 자원 계획. CCE 클러스터와 자체 구축 클러스터의 차이점에 대해 자세히 알아보려면 대상 클러스터의 리소스 계획에서 핵심 성능 매개변수를 참조하세요: 필요에 따라 리소스 계획 마이그레이션된 클러스터의 성능 구성을 상대적으로 일관성 있게 유지하는 것이 좋습니다. 원래 클러스터의 것입니다.
  • 클러스터 외부의 리소스 마이그레이션. 클러스터 외부의 관련 리소스를 마이그레이션해야 하는 경우 HUAWEI CLOUD는 해당 마이그레이션 솔루션을 제공합니다. 컨테이너 이미지 마이그레이션, 데이터베이스 및 스토리지 마이그레이션 포함
  • 마이그레이션 도구 설치. 클러스터 외부 리소스 마이그레이션이 완료되면 마이그레이션 도구를 통해 원본 클러스터와 대상 클러스터에 각각 애플리케이션 구성을 백업 및 복원할 수 있습니다.
  • 클러스터 내 리소스 마이그레이션. 오픈 소스 재해 복구 소프트웨어인 Velero와 같은 도구를 사용하여 원래 클러스터의 리소스를 오브젝트 스토리지에 백업하고 대상 클러스터에서 복원할 수 있습니다.
    • 원본 클러스터 응용 프로그램의 백업: 사용자가 백업을 수행할 때 먼저 Velero 도구를 통해 원본 클러스터에 Backup 개체를 생성하고 백업을 위해 클러스터와 관련된 데이터 및 리소스를 쿼리하고 데이터를 개체 스토리지 호환에 업로드합니다. S3 프로토콜 사용 리소스는 JSON 형식 파일로 저장됩니다.
    • 대상 클러스터 애플리케이션 복구: 대상 클러스터에서 복원할 때 Velero는 이전에 백업 데이터를 저장한 임시 개체 버킷을 지정하고 백업 데이터를 새 클러스터에 다운로드한 다음 JSON 파일에 따라 리소스를 재배포합니다. 0335802903
  • 리소스 업데이트 적응. 마이그레이션된 클러스터 리소스에는 배포할 수 없는 문제가 있을 수 있으며, 오류가 있는 리소스는 업데이트 및 적응해야 합니다.가능한 적응 문제는 주로 다음 범주를 포함합니다: 미러 업데이트 적응, 액세스 서비스 업데이트 적응, StorageClass 업데이트 적응, 데이터베이스 업데이트 적응
  • 나머지는 작동합니다. 클러스터 리소스가 정상적으로 배치된 후 마이그레이션된 애플리케이션의 기능을 확인하고 비즈니스 트래픽을 새 클러스터로 전환해야 합니다. 모든 서비스가 정상적으로 실행되고 있는지 확인한 후 원래 클러스터를 오프라인으로 전환할 수 있습니다.

HUAWEI CLOUD 컨테이너 서비스 소개

3.1 클라우드 컨테이너 엔진 CCE

• 클라우드 컨테이너 엔진은 화웨이 클라우드의 고성능 컴퓨팅(ECS/BMS), 네트워크(VPC/EIP/ELB) 스토리지(EVS/OBS/SFS) 및 기타 서비스를 깊이 통합하고 GPU 및 ARM과 같은 이기종 컴퓨팅 아키텍처를 지원한다. 영역(AZ), 다중 지역(지역) 재해 복구 및 기타 기술은 고가용성 Kubernetes 클러스터를 구축하고 확장 가능한 고성능 컨테이너 애플리케이션 관리 기능을 제공하여 클러스터 구성 및 확장을 단순화합니다.

3.2 CCE 클러스터 아키텍처 및 기능

• CCE 팀은 쿠버네티스 커뮤니티에 투자한 중국 최초의 팀이며 컨테이너 오픈 소스 커뮤니티의 주요 기여자이자 컨테이너 생태계의 리더입니다. CCE 서비스는 국내 최초 쿠버네티스 상용 제품이자 세계 최초로 CNCF 적합성 인증을 통과한 제품이다. CCE의 주요 가치는 오픈 및 오픈 소스 생태계, 향상된 상용화 기능, 유연하고 구매하기 쉬운 인프라에 있습니다.
• Volcano: 기본 K8S는 배치 컴퓨팅 비즈니스에 대한 지원이 약합니다.Volcano는 배치 컴퓨팅 분야에서 두 가지 향상된 기능을 수행했습니다.한편으로는 대기, 우선 순위, 제거, 백필, 기아 방지와 같은 고급 작업 관리를 수행했습니다. 한편으로는 토폴로지 인식 선호도 스케줄링, 동적 드라이버-실행자 비율 조정 등과 같은 지능형 스케줄링 기능이 있으며 스케줄링에서 갱 스케줄링, PS-Worker 및 기타 스케줄링 및 분산 프레임워크도 지원합니다.
• 사용자는 CCE 콘솔, Kubectl 명령줄 및 Kubernetes API를 통해 클라우드 컨테이너 엔진 서비스를 사용할 수 있습니다.

3.3 CCE 노드

• 노드는 컨테이너 클러스터의 기본 요소로, 클라우드 컨테이너 엔진 CCE에서는 고성능의 Elastic Cloud Server(ECS)나 Bare Metal Servers(BMS)를 노드로 주로 사용하여 고가용성 Kubernetes 클러스터를 구축합니다.
• 보안 컨테이너의 개념은 주로 일반 컨테이너와 비교됩니다. 일반 컨테이너와 비교할 때 가장 큰 차이점은 각 컨테이너(정확히 Pod)가 별도의 마이크로 가상 머신에서 실행되고 독립적인 운영 체제 커널과 가상화 계층의 보안 격리가 있다는 것입니다. 클라우드 컨테이너 엔진 CCE의 컨테이너 보안 격리는 사설 Kubernetes 클러스터를 독립적으로 소유하는 것보다 더 엄격한 요구 사항을 갖기 때문입니다. 보안 컨테이너를 통해 서로 다른 컨테이너의 커널 및 컴퓨팅 리소스 네트워크가 격리되어 Pod 리소스와 데이터가 다른 Pod에 의해 점유 및 도난당하지 않도록 보호합니다.
• 워크로드는 Kubernetes에서 실행되는 애플리케이션입니다. 워크로드가 단일 구성 요소이든 함께 작동하는 여러 구성 요소이든 관계없이 Kubernetes의 Pod 집합에서 실행할 수 있습니다.
• CCE는 Kubernetes 기본 유형을 기반으로 컨테이너 배포 및 관리 기능을 제공하고 컨테이너 워크로드 배포 구성, 모니터링, 확장, 업그레이드, 로드 제어, 서비스 검색 및 로드 밸런싱과 같은 수명 주기 관리를 지원합니다.

3.4 클러스터 네트워크 구성

• 네트워크 세그먼트 계획에 대한 제안:
  • 네트워크 세그먼트는 겹칠 수 없습니다. 그렇지 않으면 충돌이 발생합니다. 그리고 클러스터가 위치한 VPC 아래의 모든 서브넷(확장 네트워크 세그먼트 0 서브넷 포함)은 컨테이너 네트워크 세그먼트 및 서비스 네트워크 세그먼트와 충돌할 수 없습니다.
  • 각 네트워크 세그먼트에 사용 가능한 IP 주소가 충분한지 확인하십시오. 노드 네트워크 세그먼트의 IP 주소는 클러스터의 크기와 일치해야 하며 그렇지 않으면 IP 주소가 부족하여 노드를 생성할 수 없습니다. 컨테이너 네트워크 세그먼트의 IP 주소는 비즈니스 규모와 일치해야 하며 그렇지 않으면 IP 주소가 부족하여 포드를 생성할 수 없습니다.
• 클라우드 네이티브 네트워크 2.0 모델에서 컨테이너 네트워크 세그먼트와 노드 네트워크 세그먼트는 VPC 아래에서 네트워크 주소를 공유하므로 컨테이너 서브넷과 노드 서브넷에 동일한 58개의 서브넷을 사용하지 않는 것이 좋습니다. IP 리소스가 부족하여 컨테이너 또는 노드 생성 실패 사례.
• CCE에서 지원하는 컨테이너 네트워크 모델은 컨테이너 터널 네트워크, VPC 네트워크, 클라우드 네이티브 2.0 네트워크입니다.
• 컨테이너 터널 네트워크는 노드 네트워크를 기반으로 터널 캡슐화를 통해 노드 네트워크 평면과 독립적인 컨테이너 네트워크 평면을 구축 CCE 클러스터 컨테이너 터널 네트워크에서 사용하는 캡슐화 프로토콜은 VXLAN이며, 네트워크 패킷은 터널 전송을 위해 UDP 패킷으로 캡슐화됨 . 컨테이너 터널 네트워크는 적은 양의 터널 캡슐화 성능 손실과 함께 강력한 다용성과 상호 운용성의 이점이 있으며 성능 요구 사항이 낮은 대부분의 시나리오를 충족할 수 있습니다.

3.5 클라우드 네이티브 네트워크 2.0

• 장점: 컨테이너 네트워크에서 직접 사용하는 VPC는 ​​네트워크 문제를 해결하기 쉽고 성능이 가장 좋습니다. VPC 내부의 외부 네트워크와 컨테이너 IP 간의 직접 통신을 지원합니다. VPC에서 제공하는 로드 밸런싱, 보안 그룹, 탄력적 공용 네트워크 IP 등의 기능을 바로 사용할 수 있습니다.
• 단점: 컨테이너 네트워크에서 직접 사용하는 VPC는 ​​VPC의 주소 공간을 소비하므로 클러스터를 생성하기 전에 컨테이너 네트워크 세그먼트를 적절하게 계획해야 합니다.
• CCE Turbo 클러스터만 Cloud Native Network 2.0 사용을 지원합니다.

3.6 CCE 컨테이너 보관

• 클라우드 컨테이너 엔진 CCE의 컨테이너 스토리지 기능은 Kubernetes 스토리지 시스템을 기반으로 하며 깊이 통합된 클라우드 스토리지 서비스는 EmptyDir, HostPath, Secret, ConfigMap 및 기타 스토리지와 같은 Kubernetes 기본 스토리지 서비스와 완벽하게 호환됩니다. CCE는 Kubernetes 커뮤니티 컨테이너 스토리지 인터페이스(csl, ContainerStorage Interface)를 기반으로 클라우드 스토리지 서비스 액세스 기능을 구현하여 컨테이너 오케스트레이션 엔진과 스토리지 시스템 간에 일련의 표준 스토리지 호출 인터페이스를 설정하는 것을 목표로 합니다. 스토리지 서비스를 제공합니다
• CSI(Container Storage Interface): CSI 인터페이스를 통해 스토리지 리소스를 제공하는 컨테이너 스토리지 인터페이스 Kubernetes는 다양한 유형의 스토리지를 지원할 수 있습니다. 예를 들어 Huawei Cloud CCE는 Huawei 클라우드 블록 스토리지(EVS), 파일 스토리지(SFS) 및 개체 스토리지(OBS)에 쉽게 연결할 수 있습니다.
• CCE 클러스터의 CSI 컨테이너 스토리지 플러그인은 Everest라고 합니다. Everest는 클라우드 네이티브 컨테이너 스토리지 시스템입니다. CSI(Container Storaqe Interface)를 기반으로 Kubernetes 클러스터를 Huawei Cloud Cloud Disk Service EVS, Object Storage Service OBS와 연결합니다. , Elastic File Service SFS 및 SFS Turbo와 같은 스토리지 서비스의 초고속 파일 스토리지 기능. 이 플러그인은 시스템 리소스 플러그인으로 쿠버네티스 1.15 이상의 클러스터는 생성 시 기본적으로 설치된다.

3.7 CCE와 CCE 터보 기능 비교

3.8 자체 구축한 쿠버네티스 클러스터와 클라우드 컨테이너 엔진의 비교

3.9 컨테이너 미러링 서비스 SWR

• 간단하고 사용하기 쉬운:
  • 자체 구축 및 O&M 없이 컨테이너 이미지를 빠르게 푸시 및 풀
  • Container Image Service의 관리 콘솔은 사용하기 쉽고 이미지의 전체 수명 주기 관리를 지원합니다.
• 안전하고 신뢰할 수 있음:
  • 컨테이너 이미지 서비스는 HTTPS 프로토콜을 따라 이미지의 안전한 전송을 보장하고 계정 간 및 계정 내에서 여러 보안 격리 메커니즘을 제공하여 사용자 데이터 액세스의 보안을 보장합니다.
  • 컨테이너 이미지 서비스는 Huawei의 전문 스토리지 서비스에 의존하여 보다 안정적인 이미지 스토리지를 보장합니다.
• 미러 가속
  • 컨테이너 이미지 서비스는 Huawei의 특허받은 P2P 이미지 다운로드 가속 기술을 사용하여 CCE 클러스터가 높은 동시성을 보장하면서 더 빠른 다운로드 속도를 얻을 수 있도록 합니다.
  • 컨테이너 이미지 서비스는 글로벌 건설 노드를 지능적으로 예약하고 사용된 이미지 주소에 따라 건설을 위해 가장 가까운 호스트 노드에 자동으로 할당합니다.외부 이미지를 가져오고 로드에 따라 자동으로 유휴 노드에 할당할 수 있으므로 속도를 높일 수 있습니다. 이미지 획득의 효율성.

3.10 CCE 적용 가능한 시나리오

• 고객 및 파트너의 관행과 CCE의 기본 기능을 기반으로 다음 네 가지 시나리오를 예로 들 수 있습니다.
  • 전통적인 T-아키텍처의 점진적 변형. 가장 전통적인 아키텍처는 일반적으로 단일 대용량 애플리케이션입니다.단일 대용량 애플리케이션은 분리되어 여러 경량 모듈로 분할됩니다.각 모듈은 적응된 K8S 리소스 형식으로 수행됩니다.예를 들어 상태 비저장 애플리케이션은 배포를 사용하고 Stateful Application은 StatefulSet 등을 사용하여 각 모듈의 업그레이드 및 확장을 보다 유연하게 만들고 시장 변화에 쉽게 대응할 수 있습니다.
  • 비즈니스의 온라인 효율성을 향상시킵니다. 컨테이너 미러링은 비즈니스 운영 환경의 일관성을 보장하기 위해 개발에서 테스트, 운영 및 유지 관리에 이르는 모든 링크를 통해 실행되며 비즈니스를 즉시 사용하고 신속하게 시작할 수 있습니다.
  • 비즈니스 부하가 크게 변동하는 시나리오에 대처합니다. 컨테이너의 빠른 자동 탄력적 확장은 갑작스러운 급증 시 비즈니스 성능이 여전히 안정적임을 보장하며 시스템은 동시 피크에 신속하게 대응하기 위해 몇 초 안에 용량을 자동으로 확장합니다.
  • 자원을 절약하고 비용을 절감하십시오. 컨테이너는 가상 머신에서 보다 세분화된 방식으로 리소스를 나눌 수 있으므로 애플리케이션은 리소스를 보다 완전하게 사용할 수 있으므로 리소스 활용도가 향상됩니다.

3.11 클라우드 컨테이너 인스턴스 CCI

• 서버리스는 아키텍처 개념으로 서버를 생성하고 관리할 필요가 없으며 서버의 실행 상태(서버가 작동하는지 여부 등)에 대해 걱정할 필요가 없으며 리소스를 동적으로 적용하기만 하면 됩니다. 응용 프로그램에 필요한 서버를 전담 유지 관리 담당자에게 맡기고 관리 및 유지 관리한 다음 응용 프로그램 개발에 집중하고 응용 프로그램 개발 효율성을 향상시키고 기업 IT 비용을 절감하십시오.
• CCE는 클러스터를 관리해야 하므로 반관리형 클러스터를 제공하고 HUAWEI CLOUD는 완전 관리형 클러스터의 또 다른 유형인 HUAWEI CLOUD Cloud Container Instance CCI도 제공합니다.
• 제품 특징:
  • 원스톱 컨테이너 라이프사이클 관리: 클라우드 컨테이너 인스턴스를 사용하여 서버 클러스터를 생성 및 관리하지 않고 직접 컨테이너를 실행할 수 있습니다.
  • 여러 유형의 컴퓨팅 리소스 지원 클라우드 컨테이너 인스턴스는 0CPU, GPU 및 Ascend 칩(Huawei 자체 개발 AI 칩)을 포함하여 컨테이너를 실행하기 위한 여러 유형의 컴퓨팅 리소스를 제공합니다.
  • 여러 네트워크 액세스 방법 지원: 클라우드 컨테이너 인스턴스는 다양한 네트워크 액세스 방법을 제공하고 4계층 7계층 로드 밸런싱을 지원하며 다양한 시나리오에서 액세스 요구 사항을 충족합니다.
  • 여러 영구 스토리지 볼륨 지원: 클라우드 컨테이너 인스턴스는 HUAWEI CLOUD 클라우드 스토리지의 데이터 스토리지를 지원합니다.현재 지원되는 클라우드 스토리지에는 EVS, SFS, OBS 등이 있습니다.
  • 매우 빠른 탄력적 확장 지원: 클라우드 컨테이너 인스턴스는 사용자 정의 탄력적 확장 정책을 지원하고 여러 탄력적 정책을 자유롭게 결합하여 업무량이 급증하는 동안 갑작스러운 트래픽 급증에 대처할 수 있습니다.
  • 포괄적인 컨테이너 상태 모니터링: 클라우드 컨테이너 인스턴스는 CPU, 메모리, GPU 및 비디오 메모리 사용량을 포함하여 실행 중인 컨테이너의 리소스 사용량 모니터링을 지원합니다.
  • 전용 컨테이너 인스턴스 지원: 클라우드 컨테이너 인스턴스는 전용 컨테이너 인스턴스를 제공하고 고성능 물리적 서버를 기반으로 Kata 컨테이너를 실행하며 성능 손실 없이 가상 머신 수준에서 보안 격리를 달성합니다.

3.12 CCI 제품 아키텍처

• 사용자가 CCI를 사용할 때 기본 하드웨어 및 리소스 활용에 너무 많은 관심을 기울일 필요가 없으며 자신의 비즈니스에만 집중하면 됩니다.동시에 CCI는 주문형 및 초 단위 청구를 제공합니다. , 고객이 사용하기 편리합니다.
• 전용 컨테이너 인스턴스 테넌트는 물리적 서버를 독점적으로 점유하고 다중 부서 비즈니스 격리를 지원하며 고성능 물리적 서버를 기반으로 Kata 컨테이너를 실행하여 성능 손실 없이 가상 머신 수준의 보안 격리를 달성합니다. 서버의 업그레이드 및 유지 관리는 HUAWEI CLOUD에서 수행하며 사용자는 자신의 비즈니스에만 집중하면 됩니다.

3.13 높은 보안

• 클라우드 컨테이너 인스턴스는 컨테이너 수준의 시작 속도와 가상 머신 수준의 보안 격리 기능을 모두 갖추고 있어 더 나은 컨테이너 경험을 제공합니다.
  • 기본적으로 Kata 컨테이너를 지원합니다.
  • Kata의 커널 가상화 기술을 기반으로 포괄적인 보안 격리 및 보호 기능을 제공합니다.
  • 고성능 보안 컨테이너 확보를 위한 자체 하드웨어 가상화 가속 기술 보유

3.14 극도의 탄력성

• 예를 들어, 현재 주류 빅 데이터, AI 교육 및 추론 애플리케이션(예: Tensorflow, Caffe)은 모두 컨테이너화된 방식으로 실행되며 많은 수의 GPU, 고성능 네트워크 및 스토리지 하드웨어 가속 기능이 필요하며 태스크 많은 리소스를 빠르게 적용해야 하는 기반 컴퓨팅, 고성능 컴퓨팅, 네트워크 및 높은 IO 스토리지를 제공하고, 집약적 컴퓨팅 nw.33의 요구 사항을 충족하고, 완료 후 신속하게 컴퓨팅 작업을 릴리스합니다. 주문형 2단계 청구: 실제 사용된 리소스 수에 따라
• 비즈니스 비활성 기간의 비용을 피하고 사용자 비용을 줄이는 초당 온디맨드 청구.
• Volcano는 현재 Kubernetes에 부족한 머신 러닝, 딥 러닝, 생물 정보학, 유전체학 및 기타 빅 데이터 애플리케이션에 필요한 일련의 기능을 제공하는 Kubernetes 기반 일괄 처리 플랫폼입니다. 볼케이노는 고성능 작업 스케줄링 엔진, 고성능 이기종 칩 관리, 고성능 작업 운영 관리 등 일반적인 컴퓨팅 기능을 제공합니다. Github에서 소스 공개)

3.15 작동 및 유지보수가 필요 없음

• 사용자는 클러스터 및 서버를 인식할 필요가 없으므로 운영 및 유지 관리 작업이 크게 단순화되고 운영 및 유지 관리 비용이 절감됩니다.

3.16 적용 가능한 시나리오

• CCI는 주로 다음과 같은 작업 기반 시나리오에 적합합니다.
  • 이기종 하드웨어 지원으로 제공되는 AI 교육 및 추론 시나리오를 기반으로 교육 작업을 CCI에서 호스팅할 수 있습니다.
  • 유전자 시퀀싱 시나리오와 같은 HPC 시나리오
  • 전자 상거래 플래시 세일, 핫 마케팅 등 장기적으로 안정적인 운영 환경에서 급격한 확장 시나리오
• 주요 장점은 주문형 사용으로 인한 비용 절감, 풀 호스팅으로 인한 무료 운영 및 유지 보수, 미러 표준화로 인한 일관성 및 확장성입니다.
• 과금 방식은 종량제와 패키지 구매 두 가지가 있으며, 요금 산정을 위한 코어 시간은 코어 수 * 시간으로 계산됩니다. 1코어에 730시간을 사용할 수 있습니다.
  • 종량제 청구 모드: 인스턴스를 단위로 사용하고, 종량제 청구 모드를 채택하고, 초 단위로 청구하고, 청구 주기로 시간을 사용합니다.
  • 패키지 패키지 모드: 구매한 자원 패키지는 유효 기간 내에 있으며, 공제 방법은 구매한 자원 패키지의 금액을 먼저 공제하고 초과 부분은 주문형 결제로 정산합니다. 사용자는 리소스 팩을 반복해서 구매할 수 있으며, 리소스 팩이 여러 개일 경우 만료 시간이 가장 빠른 리소스 팩을 먼저 차감합니다.

3.17 애플리케이션 오케스트레이션 서비스 AOS

• 애플리케이션 오케스트레이션 서비스를 사용하려면 필요한 클라우드 리소스 및 애플리케이션을 설명하는 템플릿을 생성하고 템플릿에서 클라우드 리소스 및 애플리케이션의 종속성 및 참조를 정의하기만 하면 AOS가 이러한 클라우드 리소스 및 애플리케이션을 생성하고 구성합니다. 템플릿 . 예를 들어 탄력적 클라우드 서버(가상 사설 클라우드 및 서브넷 포함)를 생성하려면 탄력적 클라우드 서버, 가상 사설 클라우드 및 서브넷을 정의하는 템플릿을 작성하고 탄력적 클라우드 서버와 가상 사설 간의 종속성을 정의하기만 하면 됩니다. 클라우드, 서브넷, 서브넷 및 가상 사설 클라우드 종속성을 확인한 다음 템플릿을 사용하여 AOS를 통해 스택을 생성하면 가상 사설 클라우드, 서브넷 및 탄력적 클라우드 서버가 성공적으로 생성됩니다.
• 제품 특징:
  • 자동 오케스트레이션 리소스 지원: AOS는 자동 오케스트레이션 기능을 제공하고 HUAWEI CLOUD 주류 클라우드 서비스의 오케스트레이션을 지원합니다.자세한 내용은 오케스트레이션을 지원하는 클라우드 서비스를 참조하십시오. 또한 AOS는 리소스 계획, 애플리케이션 설계, 배포, 변경 및 기타 수명 주기 관리와 같은 관련 서비스를 제공하고 자동화를 통해 운영 및 유지 관리 비용을 절감합니다.
  • 애플리케이션 및 클라우드 서비스 리소스의 하이브리드 오케스트레이션 지원: 표준 언어(YAML/JSON)를 사용하여 필요한 기본 리소스, 애플리케이션 시스템, 애플리케이션 상위 수준 지원 서비스 및 이 세 가지 간의 관계를 설명할 수 있습니다. 통일된 설명에 따르면 한 번의 클릭으로 리소스 프로비저닝, 애플리케이션 배포 및 애플리케이션 로딩이 정의된 종속성 순서에 따라 자동으로 완료될 수 있습니다. 배포된 리소스와 애플리케이션을 통합된 방식으로 관리할 수 있습니다.
  • 풍부한 애플리케이션 템플릿 제공: AOS 템플릿 시장은 최신 애플리케이션 시나리오를 다루는 기본 리소스 템플릿, 서비스 조합 템플릿, 산업 장면 템플릿 등을 포함하여 풍부한 무료 리소스를 제공합니다. 공개 템플릿을 직접 사용하여 한 번의 클릭으로 생성하고 모든 클라우드 서비스의 2단계 배포를 완료할 수 있습니다.

3.18 멀티클라우드 컨테이너 플랫폼 MCP

• Karmada(Kubernetes Armada)는 Kubernetes 네이티브 API를 기반으로 하는 다중 클러스터 관리 시스템입니다. 멀티클라우드 및 하이브리드 클라우드 시나리오에서 Karmada는 멀티클라우드 중앙 집중식 관리, 고가용성, 오류 복구 및 트래픽 스케줄링을 달성하기 위해 멀티클러스터 애플리케이션의 플러그형 완전 자동화 관리를 제공합니다.
• 통합 클러스터 관리: 다중 클라우드 컨테이너 플랫폼은 클러스터 연합을 통해 여러 클라우드 운영자의 클러스터 통합 관리를 실현하고 동적 클러스터 액세스 및 글로벌 클러스터 모니터링 대시보드를 지원합니다.
• 글로벌 애플리케이션 관리: 다중 클러스터 및 연합 기술을 기반으로 하는 다중 클라우드 컨테이너 플랫폼은 여러 지역 및 클라우드에서 Kubernetes 관리를 실현하고 통합 글로벌 애플리케이션 관리를 지원하며 Kubernetes 커뮤니티를 기반으로 클러스터 간 애플리케이션 배포를 지원할 수 있습니다. 클러스터 연합 표준화 인터페이스, 삭제 및 업그레이드와 같은 전체 수명 주기 관리.
• 클러스터 간 탄력적 확장 기능: 다중 클라우드 컨테이너 플랫폼은 클러스터 간 애플리케이션 탄력적 확장 정책을 지원하여 각 클러스터에서 애플리케이션 인스턴스의 분산 균형을 맞추고 글로벌 로드 밸런싱을 달성합니다.
• 클러스터 간 서비스 검색 기능: 다중 클라우드 컨테이너 플랫폼은 서비스 근접 액세스 원칙에 따라 서비스의 지역 친화성을 실현하고 네트워크 지연을 줄일 수 있는 연합 서비스 및 클러스터 간 서비스 검색 메커니즘 생성을 지원합니다.
• 표준 호환성: 멀티 클라우드 컨테이너 플랫폼은 Kubernetes 커뮤니티의 최신 페더레이션 아키텍처와 호환되어 기본 Kubernetes API 및 Karada APl을 제공합니다.
• 단일 클러스터 응용 프로그램의 다중 클라우드화: 다중 클라우드 컨테이너 플랫폼은 단일 클러스터 응용 프로그램을 다중 클라우드 응용 프로그램으로 원 클릭으로 변환하고 응용 프로그램 인스턴스를 다중 클라우드 및 다중 클러스터에 배포하고 다음과 같은 시나리오를 편리하고 빠르게 완료할 수 있도록 지원합니다. 비즈니스 멀티 클라우드 재해 복구 및 멀티 클라우드 비즈니스 트래픽 공유로.
• 클러스터 간 애플리케이션 복제 및 마이그레이션 기능: 다중 클라우드 컨테이너 플랫폼은 특정 클러스터의 애플리케이션을 다른 클러스터로 복제 또는 마이그레이션하는 기능을 지원하며, 이 기능을 사용하여 클라우드 간 및 클러스터 간 애플리케이션의 활성 마이그레이션을 완료하거나 클라우드 간 및 지역 간 미러링 환경의 복제.

3.19 클라우드 네이티브 서비스 센터 OSC

• 서비스 릴리스: 서비스 제공자가 서비스 패키지를 업로드하고 OSC에서 서비스의 수명 주기 관리 및 서비스의 비즈니스 특성을 확인하고 다른 테넌트가 구독할 수 있도록 상품으로 게시합니다.
• 서비스 가입: 서비스 센터에는 Huawei의 자체 개발 서비스, 에코시스템 파트너가 출시한 서비스 및 오픈 소스 서비스가 포함됩니다.모든 서비스는 사용자 가입을 지원하며 인스턴스는 사용자 가입이 성공한 후에만 배포할 수 있습니다.
• 서비스 구독 취소: 사용자는 언제든지 서비스 구독을 취소할 수 있으며 서비스 구독을 취소하면 시스템에서 배포된 서비스 및 인스턴스를 자동으로 삭제합니다.
• 비공개 서비스 업로드: Helm, Operator Framework 또는 OSC 서비스 사양에 따라 사용자가 개발한 서비스를 비공개 서비스로 OSC에 업로드하여 관리할 수 있습니다.
• 서비스 업그레이드: 서비스 제공자가 서비스의 새 버전을 출시하면 이 서비스에 가입한 사용자는 업그레이드 프롬프트를 받게 되며 사용자는 서비스를 최신 버전으로 업그레이드할지 여부를 선택할 수 있습니다.
• 인스턴스 배포: 서비스 가입 후 인스턴스를 배포할 수 있으며 서비스 능력에 따라 배포 지역, hw3580hw3580 컨테이너 클러스터, 운영 파라미터를 지정할 수 있습니다.
• 인스턴스 O&M : 해당 인스턴스의 O&M 뷰를 제공하며, 인스턴스 모니터링, 로그 등의 O&M 정보를 조회할 수 있으며, 심도 있는 데이터 분석이 필요한 경우 O&M 뷰에서 해당 클라우드 서비스로 이동할 수 있습니다.
• 인스턴스 업데이트: 사용자는 인스턴스의 실행 구성을 수정할 수 있습니다.
• 인스턴스 삭제: 인스턴스가 수행하는 서비스 수명 주기가 종료되면 사용자는 인스턴스를 삭제하여 관련 리소스를 회수할 수 있습니다.
• 서비스 게시: 서비스 공급자가 OSC에서 상품을 관리할 수 있도록 지원하는 서비스 패키지입니다. 서비스 제공자는 먼저 서비스 패키지를 OSC에 업로드하고 형식 확인 및 취약점 스캔을 통과한 후에야 제품이 정식 출시될 수 있습니다. 서비스가 처음으로 성공적으로 출시된 후에는 새로운 버전의 서비스만 업로드하면 되며, 신규 사용자가 서비스에 가입하면 최신 버전에 가입하게 됩니다.

서버리스 개요

4.1 서버리스란?

• 서버리스 컴퓨팅은 더 이상 서버를 사용하여 코드를 호스팅하고 실행하지 않는다는 의미가 아니라 운영 엔지니어가 더 이상 필요하지 않다는 의미도 아닙니다. 이는 서버리스 컴퓨팅 소비자가 더 이상 서버 구성, 유지 관리, 업데이트, 확장 및 용량 계획에 시간과 리소스를 소비할 필요가 없다는 사실을 나타냅니다. 이러한 모든 작업과 기능은 서버리스 플랫폼에서 처리됩니다. 따라서 개발자는 애플리케이션의 비즈니스 로직을 작성하는 데 중점을 둡니다. 운영 및 유지보수 엔지니어는 주요 비즈니스 작업에 더 집중할 수 있습니다.
• 서버리스 투섬 형식:
  • FaaS(Functions-as-a-Service)는 일반적으로 이벤트 기반 컴퓨팅을 제공합니다. 개발자는 이벤트 또는 HTTP 요청에 의해 트리거되는 기능을 사용하여 애플리케이션 코드를 실행하고 관리합니다. DevFire는 서버 또는 기타 기본 인프라를 관리할 필요 없이 필요에 따라 개별 작업으로 실행되고 확장되는 FaaS 작은 코드 단위에 배포합니다.
  • BaaS(Backend-as-a-Service) 애플리케이션의 핵심 기능 하위 집합을 대체할 수 있는 API 기반 타사 서비스입니다. 이러한 API는 자동으로 확장되고 투명하게 작동하는 서비스로 제공되기 때문에 개발자에게 서버리스로 보입니다.
• 간단히 말해서 FaaS는 기능/코드 실행을 담당하고 BaaS는 애플리케이션이 의존하는 백엔드 서비스만 API 형태로 제공합니다.

4.2 서버리스의 가치

• 서버리스 제품 또는 플랫폼은 개발자에게 다음과 같은 이점을 제공합니다.
  • 제로 서버 운영: 서버리스는 서버 리소스 유지 관리와 관련된 오버헤드를 제거하여 소프트웨어 애플리케이션 실행 비용 모델을 크게 변경합니다.
    • 서버 인프라를 구성, 업데이트 및 관리할 필요가 없습니다. 서버, 가상 머신 및 컨테이너 관리는 직원, 도구, 교육 및 시간을 포함하여 회사에 상당한 비용이 듭니다.
    • 유연한 확장성: 서버리스 FaaS 또는 BaaS 오퍼링은 각 개별 수신 요청을 처리하기 위해 즉각적이고 정확하게 확장됩니다. 개발자의 경우 서버리스 플랫폼에는 "사전 계획된 용량" 개념이 없으며 "자동 크기 조정" 트리거 또는 규칙을 구성할 필요도 없습니다.
  • 유휴 상태에서 컴퓨팅 비용 없음: 소비자 관점에서 볼 때 서버리스 제품의 가장 큰 이점 중 하나는 유휴 용량에 비용이 발생하지 않는다는 것입니다. 예를 들어 서버리스 컴퓨팅 서비스는 유휴 가상 머신 또는 컨테이너에 대해 비용을 청구하지 않습니다. 즉, 코드가 실행 중이 아니거나 의미 있는 작업을 수행하지 않는 경우입니다. 물론 여기에는 상태 저장 스토리지 비용 또는 추가된 기능/특징/특징 세트와 같은 기타 비용은 포함되지 않습니다.
• 일반적으로 서버리스는 워크로드가 비동기식이고 동시적이며 독립적인 작업 단위로 병렬화하기 쉬운 경우에 권장됩니다. 확장 요구 사항에서 크고 예측할 수 없는 변화가 있는 드물거나 산발적인 요구 사항. 상태 비저장, 임시, 즉각적인 콜드 스타트 ​​시간이 크게 필요하지 않습니다. 변화하는 비즈니스 요구 사항 측면에서 매우 역동적이려면 개발자 속도를 높여야 합니다.

4.3 화웨이 서버리스 서비스-기능 그래프

• 사용자가 FunctionGraph를 사용할 때 컴퓨팅, 스토리지, 네트워크 및 기타 서비스를 활성화하거나 사전 구성할 필요가 없습니다.FunctionGraph는 서버 CPU, 메모리, 네트워크 및 기타 구성 리소스 유지 관리, 코드 배포, 탄력성을 포함한 기본 컴퓨팅 리소스를 제공하고 관리합니다 스케일링, 로드 밸런싱, 보안 업그레이드, 리소스 운영 모니터링 등을 위해 사용자는 FunctionGraph에서 지원하는 프로그래밍 언어에 따라 프로그램 패키지를 제공하고 업로드하고 실행하기만 하면 됩니다.
• 이 기능은 Node.js, Java, Python, Go, C# 및 기타 런타임 언어를 지원하고 온라인 편집 코드 OBS 파일 가져오기, ZIP 패키지 업로드, JAR 패키지 업로드 등을 지원하며 SMN, APIG 및 OBS 모니터링 지표 및 호출 기능 실행 로그의 수집 및 표시, 실시간 그래픽 모니터링 지표 표시 및 온라인 쿼리 로그를 제공하여 사용자가 기능 실행 상태를 확인하고 문제를 찾는 데 편리합니다. 여러 기능을 여러 분산 기능 작업의 실행을 조정하고 플러그인 개발 및 디버깅을 통합하는 워크플로에 여러 기능을 배열할 수 있는 FunctionGraph 기능(클라우드 및 오프 클라우드에서 일관됨), HTJP 기능은 웹 서비스 시나리오 최적화에 중점을 두고 사용자는 다음을 수행할 수 있습니다. HTTP 요청을 URL에 직접 전송 트리거 기능 실행, 사용자는 페이지 기능 구성을 통해 콜 체인 활성화 오픈 후 APM 서비스 페이지에 연결하여 ivm 및 콜 체인과 같은 정보를 볼 수 있음 현재 JAVA 기능만 지원됨 , 사용자는 플랫폼에서 로드하고 시작하는 컨테이너 이미지를 직접 패키징하고 업로드할 수 있습니다.
• FunctionGraph2.0은 차세대 함수 컴퓨팅 및 오케스트레이션 서비스입니다.
  • CloudIDE와의 심층 통합, 다기능 병렬 디버깅, 호출 체인 추적, 함수 애플리케이션 마법사 스타일 구성 및 전체 수명 주기 관리
  • 6개의 주요 프로그래밍 언어 및 맞춤형 런타임, 100밀리초 이내의 콜드 스타트 ​​지연 및 밀리초 수준의 탄력적 확장.
  • 상태 저장 기능과 시각화된 기능 오케스트레이션 기능을 지원하는 중국 최초의 제품입니다.
  • 서버리스를 달성하기 위해 웹 애플리케이션의 제로 변환을 지원합니다.

4.4 서버리스 수명 주기 관리

• 애플리케이션 개발: 클라우드의 즉시 사용 가능한 IDE 환경은 여러 클러스터 서버리스 애플리케이션에 대한 전체 체인 추적 및 커미셔닝을 지원하고 코드 중단점, 스택 보기, 호출 토폴로지 및 코드 핫 교체를 지원합니다.
• CICD: 서버리스 런타임 서비스와 긴밀하게 통합된 지속적 제공 도구 및 서버리스 애플리케이션을 위한 경량 DevOps 기능을 형성하기 위한 애플리케이션 운영 및 유지 관리 관찰 도구입니다.
• 기능 애플리케이션 호스팅: 서버리스 애플리케이션 수명 주기 관리: 서버리스 애플리케이션 사양을 통합하여 전체 애플리케이션 수명 주기 관리 기능을 제공하고 템플릿과 시장을 통해 신속한 애플리케이션 경험 및 재사용을 지원합니다.
• CAE(Cloud Application Engine)는 애플리케이션 지향 서버리스 호스팅 서비스로 매우 빠른 배포, 매우 저렴한 비용, 간소화된 운영 및 유지 관리를 통해 원스톱 애플리케이션 호스팅 솔루션을 제공합니다. 소스 코드, 소프트웨어 패키지 및 이미지 패키지, 2단계 탄력적 확장 및 종량제에서 애플리케이션의 신속한 릴리스를 지원합니다. 인프라는 운영 및 유지 보수가 필요 없으며 관찰 가능한 운영 지표에 따라 애플리케이션 수명 주기를 관리할 수 있습니다.

4.5 복잡한 비즈니스 시나리오를 지원하는 시각화된 기능 흐름

• 사용자는 시각적 레이아웃 페이지의 연결을 통해 순서도에서 이벤트 트리거, 기능 및 프로세스 컨트롤러를 연결하고 각 노드의 출력은 연결에서 다음 노드의 입력으로 사용됩니다. 프로그래밍된 프로세스는 흐름도에 설정된 순서에 따라 순차적으로 실행되며 성공적으로 실행된 후 작업 흐름의 실행 기록 보기를 지원하므로 사용자가 쉽게 진단하고 디버깅할 수 있습니다.

4.6 통합 플러그인은 클라우드 안팎에서 개발 및 디버깅을 지원합니다.

• CloudIDE 지원(클라우드에서): 템플릿을 통해 기능을 만들고, 클라우드에서 기능을 보고 클라우드로 다운로드하고, IDE를 사용하여 온라인으로 디버깅하고, 기능을 클라우드로 푸시합니다.
• VSCode 플러그인 지원(클라우드에서): 템플릿을 통해 함수 생성, 클라우드에서 함수 보기 및 로컬 디버깅으로 다운로드 VSCode 플러그인 디버깅을 사용하여 로컬 함수를 클라우드로 푸시

4.7 낮은 개조 비용

• HTTP 기능은 웹 서비스 시나리오를 최적화하는 데 중점을 두고 있으며 사용자는 HTTP 요청을 URL로 직접 보내 기능 실행을 트리거할 수 있습니다. 함수 생성 및 편집 인터페이스에 유형을 추가했습니다. HTTP 함수는 APIG/APIC 트리거 유형 생성만 허용하며 다른 트리거는 지원하지 않습니다.

4.8 컨테이너 이미지 지원

• 기존 애플리케이션 개발에서 서버리스 기능 개발로 전환하는 데에는 여전히 많은 어려움이 있습니다.
  • 런타임 및 결과물의 형식이 일정하지 않음: 서버리스 함수 공급업체에서 제공하는 일부 런타임 환경은 docker이고 일부는 microVM입니다.
  • 생태적 미성숙: 널리 사용되는 오픈 소스 도구(예: CI/CD 파이프라인)에 대한 지원 부족
• 한편, 컨테이너의 성숙한 생태계는 이식성과 민첩한 전달 문제를 매우 잘 해결했으며 컨테이너 이미지는 클라우드 네이티브 시대의 표준 결과물이 되었습니다. 그러나 컨테이너 자체는 운영 및 유지 관리를 용이하게 하지 않으며 유휴 리소스 및 기타 문제의 비용을 줄입니다.
• 개발자는 이벤트 기능에서 사용자 지정 이미지를 만들거나 HTTP 기능에서 사용자 지정 이미지를 만들 수 있습니다.

4.9 적용 가능한 시나리오

생각하는 질문

개화 종료