Knative - 서버리스 지원이 포함된 k8s 기반 Platform-as-a-Service

Kubernetes는 의심할 여지 없이 컨테이너 배포를 위한 주요 플랫폼이 되었습니다. API와 사용자 지정 리소스로 API를 확장하는 사용자 지정 컨트롤러를 사용하여 거의 모든 것을 제어할 수 있는 기능을 제공합니다.

그러나 사용자는 여전히 애플리케이션을 배포, 구성, 관리 및 확장하는 정확한 방법에 대해 세부적인 결정을 내려야 합니다. 애플리케이션 확장, 보호, 트래픽 흐름 문제는 여전히 사용자 재량에 달려 있습니다. 이는 Kubernetes를 Cloud Foundry 및 Heroku와 같은 기존 PaaS(Platform as a Service)와 차별화합니다.

플랫폼은 단순화된 사용자 인터페이스를 가지고 있으며 개별 애플리케이션 설정에 가장 자주 참여하는 애플리케이션 개발자를 대상으로 합니다. 라우팅, 배포 및 메트릭은 기본 PaaS 시스템을 통해 사용자에게 투명하게 관리됩니다.

소스에서 배송까지의 워크플로우는 PaaS에서 사용자 지정 컨테이너 이미지 생성, 배포, 수신 트래픽에 대한 새 경로 및 DNS 하위 도메인 설정을 통해 처리됩니다. 이 모든 것은 명령에 따라 시작됩니다 git push.

Kubernetes는 (의도적으로) 해당 플랫폼의 핵심 구성 요소만 제공하므로 커뮤니티가 자유롭게 작업을 수행할 수 있습니다. 어떻게 켈시 하이타워가 말했습니다.:

Kubernetes는 플랫폼 구축을 위한 플랫폼입니다. 시작하기에는 가장 좋은 위치이지만 마무리하지는 않습니다.

결과적으로 우리는 OpenShift 및 Rancher와 같이 Kubernetes용 PaaS를 생성하려는 호스팅 회사뿐만 아니라 여러 Kubernetes 빌드를 볼 수 있습니다. Kube-PaaS 시장이 성장하는 가운데 Google과 Pivotal이 2018년 XNUMX월 설립한 Knative가 링에 진입하고 있습니다.

Knative는 IBM, RedHat 및 Solo.im과 같은 다른 회사의 도움을 받아 Google과 Pivotal 간의 공동 작업이었습니다. 서버리스 컴퓨팅 기반 애플리케이션에 대한 최고의 지원을 통해 Kubernetes와 유사한 PaaS 기능을 제공합니다. Kubernetes 빌드와 달리 Knative는 호환되는 Kubernetes 클러스터에 추가 기능으로 설치되고 사용자 리소스를 통해 구성됩니다.

K네이티브란 무엇인가요?

Knative는 "최신 서버리스 컴퓨팅을 사용하여 워크로드를 제공하고 관리하기 위한 Kubernetes 기반 플랫폼"으로 설명됩니다. Knative는 자체적으로 이러한 플랫폼을 제공하는 동시에 동시 HTTP 요청에 비례하여 컨테이너 크기를 적극적으로 자동 조정합니다. 사용하지 않는 서비스는 결국 0으로 축소되어 서버리스 스타일의 온디맨드 확장을 제공합니다.

Knative는 Kubernetes 클러스터에 설치되고 다음 기능을 제공하는 컨트롤러 세트로 구성됩니다.

• 소스 코드에서 컨테이너화된 애플리케이션 구축(구성 요소에서 제공) 짓다),
• 애플리케이션에 들어오는 트래픽에 대한 액세스 제공(구성 요소에서 제공) 피복재),
• 필요에 따라 애플리케이션 제공 및 자동 확장(구성요소에서도 제공) 피복재),
• 애플리케이션 실행으로 이어지는 이벤트 소스 식별(구성요소에서 제공) 이벤트).

핵심 구성 요소는 관리형 애플리케이션에 대한 프로비저닝, 자동 크기 조정 및 트래픽 관리를 제공하는 Serving입니다. Knative를 설치한 후에도 Kubernetes API에 대한 전체 액세스 권한이 있으므로 사용자는 애플리케이션을 관리할 수 있습니다. 평소의 이러한 서비스에서 사용하는 것과 동일한 API 기본 요소(모듈, 서비스 등)로 작업하여 Knative 서비스를 디버깅하는 역할도 합니다.

Serving의 도움으로 블루-그린 트래픽 라우팅도 자동화되어 사용자가 업데이트된 애플리케이션 버전을 제공할 때 애플리케이션의 새 버전과 이전 버전 간의 트래픽 분리가 보장됩니다.

Knative 자체는 호환되는 수신 컨트롤러 설치에 따라 달라집니다. 이 글을 쓰는 시점에서는 지원됩니다. Gloo API 게이트웨이 и Istio 서비스 메시. Knative 관리 애플리케이션으로 트래픽을 라우팅하기 위해 사용 가능한 수신을 구성합니다.

Istio Service Mesh는 Knative가 게이트웨이에만 의존하기 때문에 Istio 제어판을 설치하지 않고 사용해 보려는 Knative 사용자에게 큰 종속성이 될 수 있습니다.

이러한 이유로 대부분의 사용자는 Istio와 유사한 기능 세트(Knative만 사용하는 목적)를 제공하는 동시에 훨씬 적은 리소스를 사용하고 운영 비용을 절감하는 Knative의 게이트웨이로 Gloo를 선호합니다.

스탠드에서 Knative가 실제로 작동하는지 테스트해 보겠습니다. GKE에서 실행되는 새로 설치된 클러스터를 사용하겠습니다.

kubectl get namespace
NAME          STATUS   AGE
default       Active   21h
kube-public   Active   21h
kube-system   Active   21h

Knative와 Gloo 설치를 시작해 보겠습니다. 이 작업은 어떤 순서로든 수행할 수 있습니다.

# ставим Knative-Serving
kubectl apply -f 
 https://github.com/knative/serving/releases/download/v0.8.0/serving-core.yaml
namespace/knative-serving created
# ...
# ставим Gloo
kubectl apply -f 
  https://github.com/solo-io/gloo/releases/download/v0.18.22/gloo-knative.yaml
namespace/gloo-system created
# ...

모든 Pod가 '실행 중' 상태인지 확인합니다.

kubectl get pod -n knative-serving
NAME                              READY   STATUS    RESTARTS   AGE
activator-5dd55958cc-fkp7r        1/1     Running   0          7m32s
autoscaler-fd66459b7-7d5s2        1/1     Running   0          7m31s
autoscaler-hpa-85b5667df4-mdjch   1/1     Running   0          7m32s
controller-85c8bb7ffd-nj9cs       1/1     Running   0          7m29s
webhook-5bd79b5c8b-7czrm          1/1     Running   0          7m29s
kubectl get pod -n gloo-system
NAME                                      READY   STATUS    RESTARTS   AGE
discovery-69548c8475-fvh7q                1/1     Running   0          44s
gloo-5b6954d7c7-7rfk9                     1/1     Running   0          45s
ingress-6c46cdf6f6-jwj7m                  1/1     Running   0          44s
knative-external-proxy-7dd7665869-x9xkg   1/1     Running   0          44s
knative-internal-proxy-7775476875-9xvdg   1/1     Running   0          44s

Gloo는 라우팅할 준비가 되었습니다. 자동 확장 Knative 서비스(kservice라고 함)를 생성하고 트래픽을 라우팅해 보겠습니다.

Knative 서비스는 기존 배포+서비스+인그레스 모델보다 Kubernetes에 애플리케이션을 제공하는 더 쉬운 경로를 제공합니다. 우리는 다음 예제를 다룰 것입니다:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
 name: helloworld-go
 namespace: default
spec:
 template:
   spec:
     containers:
       - image: gcr.io/knative-samples/helloworld-go
         env:
           - name: TARGET
             Value: Knative user

이것을 파일에 복사한 다음 다음과 같이 Kubernetes 클러스터에 적용했습니다.

kubectl apply -f ksvc.yaml -n default

'helloworld-go'를 전달한 후 클러스터에서 Knative가 생성한 리소스를 볼 수 있습니다. kservice:

kubectl get pod -n default
NAME                                              READY   STATUS    RESTARTS   AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8   2/2     Running   0          68s

kservice가 배포되면 'helloworld-go' 이미지가 포함된 포드가 시작됩니다. 트래픽이 없으면 포드 수가 0으로 줄어듭니다. 반대로 동시 요청 수가 특정 구성 가능한 임계값을 초과하면 Pod 수가 증가합니다.

kubectl get ingresses.networking.internal.knative.dev -n default
NAME            READY   REASON
helloworld-go   True

Knative는 내부 Knative API의 특수 '수신' 리소스를 사용하여 수신을 구성합니다. Gloo는 이 API를 구성으로 사용하여 블루-그린 배포 모델, 자동 TLS 시행, 시간 초과 및 기타 고급 라우팅 기능을 포함한 PaaS와 유사한 기능을 제공합니다.

얼마 후, Pod가 사라진 것을 확인할 수 있습니다(수신 트래픽이 없기 때문에).

kubectl get pod -n default

No resources found.
kubectl get deployment -n default
NAME                             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

마지막으로 우리는 그들에게 다가가려고 노력할 것입니다. 다음을 사용하여 Knative Proxy의 URL을 쉽고 쉽게 얻을 수 있습니다. glooctl:

glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80

설치하지 않고 glooctl kube 서비스에서 주소와 포트를 볼 수 있습니다.

kubectl get svc -n gloo-system knative-external-proxy
NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      AGE
knative-external-proxy   LoadBalancer   10.16.11.157   35.190.151.188   80:32168/TCP,443:30729/TCP   77m

cURL을 사용하여 일부 데이터를 실행해 보겠습니다.

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!

Knative는 Gloo의 고성능 풀 스택 API 게이트웨이를 사용하여 즉시 사용 가능한 Kubernetes를 기반으로 개발자에게 거의 PaaS에 가까운 서비스를 제공합니다. 이 게시물에서는 Knative의 광범위한 사용자 정의 옵션과 추가 기능을 표면적으로만 살펴보았습니다. 글루도 마찬가지!

Knative는 아직 초기 프로젝트임에도 불구하고 팀은 6주마다 새 버전을 출시하고 자동 TLS 배포, 제어판 자동 크기 조정과 같은 고급 기능 구현이 시작되었습니다. 여러 클라우드 회사 간의 협업과 Google의 새로운 Cloud Run 제품의 기반으로 Knative가 Kubernetes의 서버리스 컴퓨팅 및 PaaS를 위한 기본 옵션이 될 가능성이 높습니다. 뉴스를 팔로우하세요!

SouthBridge 편집자로부터
독자의 의견은 우리에게 중요하므로 Knative, Kubernetes, 서버리스 컴퓨팅에 대한 향후 기사와 관련된 간단한 설문 조사에 참여해 주시기 바랍니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

Knative 및 서버리스 컴퓨팅에 대한 기사와 가이드를 계속 작성해야 합니까?

• 제발.

• 고마워, 하지마.

28명의 사용자가 투표했습니다. 4명의 사용자가 기권했습니다.

출처 : habr.com