6.8. Service Binding Operator를 사용한 바인딩 워크로드


애플리케이션 개발자는 바인딩 보안을 사용하여 워크로드를 하나 이상의 백업 서비스에 바인딩해야 합니다. 이 시크릿은 워크로드에서 사용할 정보를 저장하기 위해 생성됩니다.

예를 들어 연결하려는 서비스가 이미 바인딩 데이터를 노출한다고 가정합니다. 이 경우 ServiceBinding CR(사용자 정의 리소스)과 함께 사용할 워크로드가 필요합니다. 이 ServiceBinding CR을 사용하면 워크로드가 바인딩할 서비스 세부 정보와 함께 바인딩 요청을 보냅니다.

ServiceBinding CR의 예

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
    name: spring-petclinic-pgcluster
    namespace: my-petclinic
spec:
    services: 1
    - group: postgres-operator.crunchydata.com
      version: v1beta1
      kind: PostgresCluster
      name: hippo
    application: 2
      name: spring-petclinic
      group: apps
      version: v1
      resource: deployments

1
서비스 리소스 목록을 지정합니다.
2
포함된 PodSpec이 있는 Deployment 또는 기타 유사한 리소스를 가리키는 샘플 애플리케이션입니다.

이전 예에서와 같이 바인딩 데이터 소스로 사용할 ConfigMap 또는 Secret 자체를 서비스 리소스로 직접 사용할 수도 있습니다.

6.8.1. 전략 이름 지정

명명 전략은 binding.operators.coreos.com API 그룹에만 사용할 수 있습니다.

이름 지정 전략에서는 Go 템플릿을 사용하여 서비스 바인딩 요청을 통해 사용자 정의 바인딩 이름을 정의하는 데 도움이 됩니다. 이름 지정 전략은 ServiceBinding CR(사용자 정의 리소스)의 매핑을 포함하여 모든 속성에 적용됩니다.

백업 서비스 프로젝트는 바인딩 이름이 파일 또는 환경 변수로 워크로드에 포함됩니다. 워크로드에 특정 형식으로 예상된 바인딩 이름이 예상되지만 백업 서비스에서 프로젝션할 바인딩 이름은 해당 형식으로 사용할 수 없는 경우 이름 지정 전략을 사용하여 바인딩 이름을 변경할 수 있습니다.

사전 정의된 후 처리 함수

워크로드의 기대치 또는 요구 사항에 따라 이름 지정 전략을 사용하는 동안 다음과 같은 사전 정의된 후 처리 함수를 조합하여 사용하여 문자 문자열을 변환할 수 있습니다.

  • 대문자: 문자 문자열을 대문자 또는 대문자로 변환합니다.
  • lower: 문자 문자열을 소문자로 변환합니다.
  • title: 각 단어의 첫 글자가 특정 사소한 단어를 제외한 대문자를 대문자로 변환하는 문자 문자열을 변환합니다.

사전 정의된 이름 지정 전략

주석을 통해 선언된 바인딩 이름은 다음과 같은 사전 정의된 명명 전략에 따라 예상되기 전에 이름 변경에 대해 처리됩니다.

  • None: 적용될 때, 바인딩 이름에 변경 사항이 없습니다.

    예제

    템플릿 컴파일 후 바인딩 이름은 {{ .name }} 형식을 사용합니다.

    host: hippo-pgbouncer
    port: 5432
  • upper: namingStrategy 가 정의되지 않은 경우 적용됩니다. 적용되는 경우 바인딩 이름 키의 모든 문자 문자열을 대문자 또는 대문자로 변환합니다.

    예제

    템플릿 컴파일 후 바인딩 이름은 {{ .service.kind | upper}}_{{ .name | upper }} 형식을 사용합니다.

    DATABASE_HOST: hippo-pgbouncer
    DATABASE_PORT: 5432

    워크로드에 다른 형식이 필요한 경우 사용자 정의 이름 지정 전략을 정의하고 접두사 및 구분 기호(예: PORT_DATABASE )를 사용하여 바인딩 이름을 변경할 수 있습니다.

참고
  • 바인딩 이름이 파일로 프로젝션되면 기본적으로 사전 정의된 명명 전략이 적용되지 않으며 바인딩 이름은 변경되지 않습니다.
  • 바인딩 이름이 환경 변수로 예상되고 namingStrategy 가 정의되지 않은 경우 기본적으로 사전 정의된 대문자 이름 설정이 적용됩니다.
  • 사용자 지정 바인딩 이름과 사전 정의된 후 처리 함수의 다양한 조합을 사용하여 사용자 정의 이름 지정 전략을 정의하여 사전 정의된 이름 지정 전략을 재정의할 수 있습니다.

6.8.2. 고급 바인딩 옵션

다음과 같은 고급 바인딩 옵션을 사용하도록 ServiceBinding CR(사용자 정의 리소스)을 정의할 수 있습니다.

  • 바인딩 이름 변경: 이 옵션은 binding.operators.coreos.com API 그룹에만 사용할 수 있습니다.
  • 사용자 정의 바인딩 데이터 구성: 이 옵션은 binding.operators.coreos.com API 그룹에만 사용할 수 있습니다.
  • 라벨 선택기를 사용한 바인딩 워크로드: 이 옵션은 binding.operators.coreos.comservicebinding.io API 그룹 모두에서 사용할 수 있습니다.

6.8.2.1. 워크로드에 프로젝션하기 전에 바인딩 이름 변경

ServiceBinding CR의 .spec.namingStrategy 특성에서 바인딩 이름을 변경하는 규칙을 지정할 수 있습니다. 예를 들어 PostgreSQL 데이터베이스에 연결하는 Spring PetClinic 샘플 애플리케이션을 고려해 보십시오. 이 경우 PostgreSQL 데이터베이스 서비스는 바인딩에 사용할 데이터베이스의 호스트포트 필드를 노출합니다. Spring PetClinic 샘플 애플리케이션은 바인딩 이름을 통해 노출된 바인딩 데이터에 액세스할 수 있습니다.

예: ServiceBinding CR의 Spring PetClinic 샘플 애플리케이션

# ...
    application:
      name: spring-petclinic
      group: apps
      version: v1
      resource: deployments
# ...

예: ServiceBinding CR의 PostgreSQL 데이터베이스 서비스

# ...
    services:
    - group: postgres-operator.crunchydata.com
      version: v1beta1
      kind: PostgresCluster
      name: hippo
# ...

namingStrategy 가 정의되지 않고 바인딩 이름이 환경 변수로 예상되는 경우 백업 서비스의 host: hippo-pgbouncer 값과 예상된 환경 변수가 다음 예와 같이 표시됩니다.

예제

DATABASE_HOST: hippo-pgbouncer

다음과 같습니다.

DATABASE

kind backend 서비스를 지정합니다.

HOST

바인딩 이름을 지정합니다.

POSTGRESQL_{{ .service.kind | upper }}_{{ .name | upper }}_ENV 이름 전략을 적용하면 서비스 바인딩 요청에 의해 준비된 사용자 정의 바인딩 이름 목록이 다음 예와 같이 표시됩니다.

예제

POSTGRESQL_DATABASE_HOST_ENV: hippo-pgbouncer
POSTGRESQL_DATABASE_PORT_ENV: 5432

다음 항목에서는 POSTGRESQL_{{ .service.kind | upper }}_{{ .name | upper }}_ENV 이름 설정에 정의된 표현식을 설명합니다.

  • .name: 백업 서비스에서 노출하는 바인딩 이름을 유추합니다. 이전 예에서 바인딩 이름은 HOSTPORT 입니다.
  • .service.kind: 바인딩 이름이 이름 지정 전략을 사용하여 변경되는 서비스 리소스 종류를 유추합니다.
  • upper: Go 템플릿 문자열을 컴파일하는 동안 문자 문자열을 사후 처리하는 데 사용되는 문자열 함수입니다.
  • POSTGRESQL: 사용자 정의 바인딩 이름의 접두사입니다.
  • ENV: 사용자 정의 바인딩 이름의 suffix.

이전 예제와 유사하게 namingStrategy 에서 문자열 템플릿을 정의하여 서비스 바인딩 요청으로 바인딩 이름의 각 키를 준비하는 방법을 정의할 수 있습니다.

6.8.2.2. 사용자 정의 바인딩 데이터 구성

애플리케이션 개발자는 다음 상황에서 사용자 지정 바인딩 데이터를 작성할 수 있습니다.

  • 백업 서비스는 바인딩 데이터를 노출하지 않습니다.
  • 노출된 값은 워크로드에서 예상대로 필요한 형식으로 사용할 수 없습니다.

예를 들어 백업 서비스 CR에서 호스트, 포트 및 데이터베이스 사용자를 바인딩 데이터로 표시하는 경우를 생각해 보십시오. 그러나 워크로드에서는 바인딩 데이터를 연결 문자열로 사용해야 합니다. 지원 서비스를 나타내는 Kubernetes 리소스의 속성을 사용하여 사용자 정의 바인딩 데이터를 작성할 수 있습니다.

예제

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
    name: spring-petclinic-pgcluster
    namespace: my-petclinic
spec:
    services:
    - group: postgres-operator.crunchydata.com
      version: v1beta1
      kind: PostgresCluster
      name: hippo 1
      id: postgresDB 2
    - group: ""
      version: v1
      kind: Secret
      name: hippo-pguser-hippo
      id: postgresSecret
    application:
      name: spring-petclinic
      group: apps
      version: v1
      resource: deployments
    mappings:
      ## From the database service
      - name: JDBC_URL
        value: 'jdbc:postgresql://{{ .postgresDB.metadata.annotations.proxy }}:{{ .postgresDB.spec.port }}/{{ .postgresDB.metadata.name }}'
      ## From both the services!
      - name: CREDENTIALS
        value: '{{ .postgresDB.metadata.name }}{{ translationService.postgresSecret.data.password }}'
      ## Generate JSON
      - name: DB_JSON 3
        value: {{ json .postgresDB.status }} 4

1
백업 서비스 리소스의 이름입니다.
2
선택적 식별자입니다.
3
Service Binding Operator가 생성하는 JSON 이름입니다. Service Binding Operator는 이 JSON 이름을 파일 또는 환경 변수의 이름으로 생성합니다.
4
Service Binding Operator가 생성하는 JSON 값입니다. Service Binding Operator는 이 JSON 값을 파일 또는 환경 변수로 생성합니다. JSON 값에는 백업 서비스 사용자 정의 리소스의 지정된 필드의 속성이 포함됩니다.

6.8.2.3. 라벨 선택기를 사용하여 워크로드 바인딩

라벨 선택기를 사용하여 바인딩할 워크로드를 지정할 수 있습니다. 라벨을 사용하여 워크로드 선택기를 사용하여 서비스 바인딩을 선언하면 Service Binding Operator는 지정된 라벨 선택기와 일치하는 새 워크로드를 주기적으로 찾고 바인딩합니다.

예를 들어 클러스터 관리자는 ServiceBinding CR에서 적절한 labelSelector 필드를 설정하여 environment: production 라벨을 사용하여 네임스페이스의 모든 Deployment 에 서비스를 바인딩할 수 있습니다. 이를 통해 Service Binding Operator가 이러한 각 워크로드를 하나의 ServiceBinding CR에 바인딩할 수 있습니다.

binding.operators.coreos.com/v1alpha1 API의 ServiceBinding CR 예

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
  name: multi-application-binding
  namespace: service-binding-demo
spec:
  application:
    labelSelector: 1
      matchLabels:
        environment: production
    group: apps
    version: v1
    resource: deployments
  services:
    group: ""
    version: v1
    kind: Secret
    name: super-secret-data

1
바인딩되는 워크로드를 지정합니다.

servicebinding.io API의 ServiceBinding CR 예

apiVersion: servicebindings.io/v1beta1
kind: ServiceBinding
metadata:
  name: multi-application-binding
  namespace: service-binding-demo
spec:
  workload:
    selector: 1
      matchLabels:
        environment: production
    apiVersion: app/v1
    kind: Deployment
  service:
    apiVersion: v1
    kind: Secret
    name: super-secret-data

1
바인딩되는 워크로드를 지정합니다.
중요

다음 필드 쌍을 정의한 경우 Service Binding Operator는 바인딩 작업을 거부하고 오류를 생성합니다.

  • binding.operators.coreos.com/v1alpha1 API의 namelabelSelector 필드입니다.
  • servicebinding.io API(Spec API)의 nameselector 필드입니다.

rebinding 동작 이해

바인딩에 성공한 후 name 필드를 사용하여 워크로드를 식별하는 경우를 고려하십시오. 해당 워크로드를 삭제하고 다시 생성하는 경우 ServiceBinding 조정기에서 워크로드를 다시 바인딩하지 않으며 Operator는 바인딩 데이터를 워크로드에 대해 프로젝션할 수 없습니다. 그러나 labelSelector 필드를 사용하여 워크로드를 식별하는 경우 ServiceBinding 조정기에서 워크로드를 다시 바인딩하고 Operator에서 바인딩 데이터를 프로젝트를 해제합니다.

6.8.3. PodSpec을 준수하지 않는 보조 워크로드 바인딩

서비스 바인딩의 일반적인 시나리오에는 백업 서비스, 배포(배포) 및 Service Binding Operator를 구성해야 합니다. PodSpec을 준수하지 않고 기본 워크로드 (Deployment) 및 Service Binding Operator 사이에 있는 보조 워크로드(애플리케이션 Operator)가 포함된 시나리오를 고려하십시오.

이러한 보조 워크로드 리소스의 경우 컨테이너 경로의 위치는 임의적입니다. 서비스 바인딩의 경우 CR의 보조 워크로드가 PodSpec과 일치하지 않는 경우 컨테이너 경로의 위치를 지정해야 합니다. 이렇게 하면 Pod 내의 바인딩 데이터를 원하지 않는 경우와 같이 ServiceBinding CR(사용자 정의 리소스)의 보조 워크로드에 지정된 컨테이너 경로에 바인딩 데이터를 바인딩합니다.

Service Binding Operator에서는 워크로드 내에 컨테이너 또는 보안이 상주하는 경로를 구성하고 사용자 정의 위치에서 이러한 경로를 바인딩할 수 있습니다.

6.8.3.1. 컨테이너 경로의 사용자 정의 위치 구성

이 사용자 지정 위치는 Service Binding Operator가 환경 변수로 바인딩 데이터를 프로젝트하는 경우 binding.operators.coreos.com API 그룹에 사용할 수 있습니다.

PodSpec을 준수하지 않고 spec.containers 경로에 컨테이너가 있는 보조 워크로드 CR을 고려하십시오.

예: 보조 워크로드 CR

apiVersion: "operator.sbo.com/v1"
kind: SecondaryWorkload
metadata:
    name: secondary-workload
spec:
    containers:
    - name: hello-world
      image: quay.io/baijum/secondary-workload:latest
      ports:
      - containerPort: 8080

절차

  • ServiceBinding CR에 값을 지정하여 spec.containers 경로를 구성하고 이 경로를 spec.application.bindingPath.containersPath 사용자 지정 위치에 바인딩합니다.

    예: 사용자 정의 위치에서 spec.containers 경로를 사용한 ServiceBinding CR

    apiVersion: binding.operators.coreos.com/v1alpha1
    kind: ServiceBinding
    metadata:
        name: spring-petclinic-pgcluster
    spec:
        services:
        - group: postgres-operator.crunchydata.com
          version: v1beta1
          kind: PostgresCluster
          name: hippo
          id: postgresDB
        - group: ""
          version: v1
          kind: Secret
          name: hippo-pguser-hippo
          id: postgresSecret
        application: 1
          name: spring-petclinic
          group: apps
          version: v1
          resource: deployments
        application: 2
          name: secondary-workload
          group: operator.sbo.com
          version: v1
          resource: secondaryworkloads
          bindingPath:
            containersPath: spec.containers 3

    1
    포함된 PodSpec이 있는 Deployment 또는 기타 유사한 리소스를 가리키는 샘플 애플리케이션입니다.
    2
    보조 워크로드는 PodSpec을 준수하지 않습니다.
    3
    컨테이너 경로의 사용자 지정 위치입니다.

컨테이너 경로의 위치를 지정하면 Service Binding Operator가 바인딩 데이터를 생성하여 ServiceBinding CR의 보조 워크로드에 지정된 컨테이너 경로에서 사용할 수 있게 됩니다.

다음 예제는 envFromsecretRef 필드가 있는 spec.containers 경로를 보여줍니다.

예: envFromsecretRef 필드가 있는 보조 워크로드 CR

apiVersion: "operator.sbo.com/v1"
kind: SecondaryWorkload
metadata:
    name: secondary-workload
spec:
    containers:
    - env: 1
      - name: ServiceBindingOperatorChangeTriggerEnvVar
        value: "31793"
      envFrom:
      - secretRef:
          name: secret-resource-name 2
      image: quay.io/baijum/secondary-workload:latest
      name: hello-world
      ports:
      - containerPort: 8080
      resources: {}

1
Service Binding Operator에서 생성한 값이 있는 고유한 컨테이너 배열입니다. 이러한 값은 백업 서비스 CR을 기반으로 합니다.
2
Service Binding Operator에서 생성한 Secret 리소스의 이름입니다.

6.8.3.2. 보안 경로의 사용자 정의 위치 구성

이 사용자 지정 위치는 Service Binding Operator가 환경 변수로 바인딩 데이터를 프로젝트하는 경우 binding.operators.coreos.com API 그룹에 사용할 수 있습니다.

spec.secret 경로의 보안만 사용하여 PodSpec을 준수하지 않는 보조 워크로드 CR을 고려하십시오.

예: 보조 워크로드 CR

apiVersion: "operator.sbo.com/v1"
kind: SecondaryWorkload
metadata:
    name: secondary-workload
spec:
    secret: ""

절차

  • ServiceBinding CR에 값을 지정하여 spec.secret 경로를 구성하고 spec.application.bindingPath.secretPath 사용자 정의 위치에서 이 경로를 바인딩합니다.

    예: 사용자 정의 위치에서 spec.secret 경로를 사용한 ServiceBinding CR

    apiVersion: binding.operators.coreos.com/v1alpha1
    kind: ServiceBinding
    metadata:
        name: spring-petclinic-pgcluster
    spec:
    ...
        application: 1
          name: secondary-workload
          group: operator.sbo.com
          version: v1
          resource: secondaryworkloads
          bindingPath:
            secretPath: spec.secret 2
    ...

    1
    보조 워크로드는 PodSpec을 준수하지 않습니다.
    2
    Secret 리소스의 이름이 포함된 보안 경로의 사용자 정의 위치입니다.

보안 경로의 위치를 지정하면 Service Binding Operator가 바인딩 데이터를 생성하여 ServiceBinding CR의 보조 워크로드에 지정된 보안 경로에서 사용할 수 있게 됩니다.

다음 예제에서는 binding-request 값이 있는 spec.secret 경로를 보여줍니다.

예: binding-request 값을 사용한 보조 워크로드 CR

...
apiVersion: "operator.sbo.com/v1"
kind: SecondaryWorkload
metadata:
    name: secondary-workload
spec:
    secret: binding-request-72ddc0c540ab3a290e138726940591debf14c581 1
...

1
Service Binding Operator가 생성하는 Secret 리소스의 고유한 이름입니다.

6.8.3.3. 워크로드 리소스 매핑

참고
  • 워크로드 리소스 매핑은 API 그룹 binding.operators.coreos.comservicebinding.io.io 모두에서 ServiceBinding CR(사용자 정의 리소스)의 보조 워크로드에 사용할 수 있습니다.
  • servicebinding.io API 그룹에서만 ClusterWorkloadResourceMapping 리소스를 정의해야 합니다. 그러나 ClusterWorkloadResourceMapping 리소스는 binding.operators.coreos.comservicebinding.io API 그룹 모두에서 ServiceBinding 리소스와 상호 작용합니다.

컨테이너 경로에 대한 구성 방법을 사용하여 사용자 정의 경로 위치를 구성할 수 없는 경우 바인딩 데이터를 예상해야 하는 정확한 위치를 정의할 수 있습니다. servicebinding.io API 그룹에서 ClusterWorkloadResourceMapping 리소스를 정의하여 지정된 워크로드 종류의 바인딩 데이터를 프로젝션할 위치를 지정합니다.

다음 예제에서는 CronJob.batch/v1 리소스에 대한 매핑을 정의하는 방법을 보여줍니다.

예: CronJob.batch/v1 리소스의 매핑

apiVersion: servicebinding.io/v1beta1
kind: ClusterWorkloadResourceMapping
metadata:
 name: cronjobs.batch 1
spec:
  versions:
  - version: "v1" 2
    annotations: .spec.jobTemplate.spec.template.metadata.annotations 3
    containers:
    - path: .spec.jobTemplate.spec.template.spec.containers[*] 4
    - path: .spec.jobTemplate.spec.template.spec.initContainers[*]
      name: .name 5
      env: .env 6
      volumeMounts: .volumeMounts 7
    volumes: .spec.jobTemplate.spec.template.spec.volumes 8

1
매핑된 워크로드 리소스의 plural.group 으로 자격이 있어야 하는 ClusterWorkloadResourceMapping 리소스의 이름입니다.
2
매핑 중인 리소스의 버전입니다. 지정되지 않은 모든 버전은 "*" 와일드카드와 일치시킬 수 있습니다.
3
선택사항: 고정 JSONPath로 지정된 Pod의 .annotations 필드의 식별자입니다. 기본값은 .spec.template.spec.annotations 입니다.
4
Pod의 .containers.initContainers 필드의 식별자로 JSONPath로 지정됩니다. containers 필드의 항목이 정의되지 않은 경우 Service Binding Operator는 기본적으로 .spec.template.spec.containers[*].spec.template.spec.initContainers[\*].spec.template.initContainers[\*]의 두 가지 경로로 설정되고 다른 모든 필드는 기본값으로 설정됩니다. 그러나 항목을 지정하는 경우 .path 필드를 정의해야 합니다.
5
선택 사항: 고정된 JSONPath로 지정된 컨테이너에서 .name 필드의 식별자입니다. 기본값은 .name 입니다.
6
선택 사항: 고정된 JSONPath로 지정된 컨테이너의 .env 필드 식별자입니다. 기본값은 .env 입니다.
7
선택사항: 고정된 JSONPath로 지정된 컨테이너의 .volumeMounts 필드 식별자입니다. 기본값은 .volumeMounts 입니다.
8
선택사항: 고정 JSONPath로 지정된 Pod의 .volumes 필드의 식별자입니다. 기본값은 .spec.template.spec.volumes 입니다.
중요
  • 이 컨텍스트에서 고정 JSONPath는 다음 작업만 허용하는 JSONPath grammar의 하위 집합입니다.

    • 필드 조회: .spec.template
    • 배열 인덱싱: .spec['template']

    다른 모든 작업은 허용되지 않습니다.

  • 이러한 필드의 대부분은 선택 사항입니다. 이를 지정하지 않으면 Service Binding Operator에서 기본적으로 PodSpec 리소스와 호환되는 것으로 가정합니다.
  • Service Binding Operator를 사용하려면 이러한 각 필드가 Pod 배포의 해당 필드와 구조적으로 일치해야 합니다. 예를 들어 워크로드 리소스의 .env 필드 콘텐츠에서는 Pod 리소스의 .env 필드와 동일한 구조의 데이터를 허용할 수 있어야 합니다. 그렇지 않으면 이러한 워크로드에 바인딩 데이터를 프로젝션하면 Service Binding Operator에서 예기치 않은 동작이 발생할 수 있습니다.

binding.operators.coreos.com API 그룹과 관련된 동작

ClusterWorkloadResourceMapping 리소스가 binding.operators.coreos.com API 그룹의 ServiceBinding 리소스와 상호 작용할 때 다음 동작을 기대할 수 있습니다.

  • bindAsFiles: false 플래그 값이 있는 ServiceBinding 리소스가 이러한 매핑 중 하나와 함께 생성되는 경우 환경 변수는 해당 ClusterWorkloadResourceMapping 리소스에 지정된 각 경로 필드 아래의 .envFrom 필드에 프로젝션됩니다.
  • 클러스터 관리자는 바인딩을 위해 ServiceBinding.bindings.coreos.com 리소스에서 ClusterWorkloadResourceMapping 리소스와 .spec.application.bindingPath.containersPath 필드를 모두 지정할 수 있습니다.

    Service Binding Operator는 ClusterWorkloadResourceMapping 리소스 및 .spec.application.bindingPath.containersPath 필드에 지정된 위치에 바인딩 데이터를 프로젝트 지정하려고 합니다. 이 동작은 path: $containersPath 속성과 함께 해당 ClusterWorkloadResourceMapping 리소스에 컨테이너 항목을 추가하는 것과 같습니다. 다른 모든 값은 기본값을 사용합니다.

6.8.4. 백업 서비스에서 워크로드 바인딩 해제

oc 툴을 사용하여 백업 서비스에서 워크로드를 바인딩 해제할 수 있습니다.

  • 백업 서비스에서 워크로드를 바인딩 해제하려면 ServiceBinding CR(사용자 정의 리소스)에 연결된 ServiceBinding을 삭제합니다.

    $ oc delete ServiceBinding <.metadata.name>

    예제

    $ oc delete ServiceBinding spring-petclinic-pgcluster

    다음과 같습니다.

    spring-petclinic-pgcluster

    ServiceBinding CR의 이름을 지정합니다.

6.8.5. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.