이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 13. Configuring Skupper sites using YAML


Using YAML files to configure Skupper allows you to use source control to track and manage Skupper network changes.

13.1. Creating a Skupper site using YAML

Using YAML files to create Skupper sites allows you to use source control to track and manage Skupper network changes.

Prerequisites

  • Skupper is installed in the cluster or namespace you want to target.
  • You are logged into the cluster.

Procedure

  1. Create a YAML file to define the site, for example, my-site.yaml:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: skupper-site
    data:
      name: my-site
      console: "true"
      console-user: "admin"
      console-password: "changeme"
      flow-collector: "true"

    The YAML creates a site with a console and you can create tokens from this site.

    To create a site that has no ingress:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: skupper-site
    data:
      name: my-site
      ingress: "none"
  2. Apply the YAML file to your cluster:

    kubectl apply -f ~/my-site.yml

Additional resources

See the Section 13.3, “Site ConfigMap YAML reference” section for more reference.

13.2. Configuring services using annotations

After creating and linking sites, you can use Kubernetes annotations to control which services are available on the service network.

13.2.1. Exposing simple services on a service network using annotations

This section provides an alternative to the skupper expose command, allowing you to annotate existing resources to expose simple services on the service network.

Prerequisites

  • A site with a service you want to expose

Procedure

  1. Log into the namespace in your cluster that is configured as a site.
  2. Create a deployment, some pods, or a service in one of your sites, for example:

    $ kubectl create deployment hello-world-backend --image quay.io/skupper/hello-world-backend

    This step is not Skupper-specific, that is, this process is unchanged from standard processes for your cluster.

  3. Annotate the kubernetes resource to create a service that can communicate on the service network, for example:

    $ kubectl annotate deployment backend "skupper.io/address=backend" "skupper.io/port=8080" "skupper.io/proxy=tcp"

    The annotations include:

    • skupper.io/proxy - the protocol you want to use, tcp, http or http2. This is the only annotation that is required. For example, if you annotate a simple deployment named backend with skupper.io/proxy=tcp, the service is exposed as backend and the containerPort value of the deployment is used as the port number.
    • skupper.io/address - the name of the service on the service network.
    • skupper.io/port - one or more ports for the service on the service network.
    Note

    When exposing services, rather than other resources like deployments, you can use the skupper.io/target annotation to avoid modifying the original service. For example, if you want to expose the backend service:

    $ kubectl annotate service backend "skupper.io/address=van-backend" "skupper.io/port=8080" \
    "skupper.io/proxy=tcp" "skupper.io/target=backend"

    This allows you to delete and recreate the backend service without having to apply the annotation again.

  4. Check that you have exposed the service:

    $ skupper service status -v
    Services exposed through Skupper:
    ╰─ backend:8080 (tcp)
       ╰─ Sites:
          ├─ 4d80f485-52fb-4d84-b10b-326b96e723b2(west)
          │  policy: disabled
          ╰─ 316fbe31-299b-490b-9391-7b46507d76f1(east)
             │ policy: disabled
             ╰─ Targets:
                ╰─ backend:8080 name=backend-9d84544df-rbzjx
    Note

    The related targets for services are only displayed when the target is available on the current cluster.

13.2.2. Understanding Skupper annotations

Annotations allow you to expose services on the service network. This section provides details on the scope of those annotations

skupper.io/address

The name of the service on the service network. Applies to:

  • Deployments
  • StatefulSets
  • DaemonSets
  • Services
skupper.io/port

The port for the service on the service network. Applies to:

  • Deployments
  • StatefulSets
  • DaemonSets
skupper.io/proxy

The protocol you want to use, tcp, http or http2. Applies to:

  • Deployments
  • StatefulSets
  • DaemonSets
  • Services
skupper.io/target

The name of the target service you want to expose. Applies to:

  • Services
skupper.io/service-labels

A comma separated list of label keys and values for the exposed service. You can use this annotation to set up labels for monitoring exposed services. Applies to:

  • Deployments
  • DaemonSets
  • Services

13.3. Site ConfigMap YAML reference

Using YAML files to configure Skupper requires that you understand all the fields so that you provision the site you require.

The following YAML defines a Skupper site:

apiVersion: v1
data:
  name: my-site
  console: "true"
  flow-collector: "true"
  console-authentication: internal
  console-user: "username"
  console-password: "password"
  cluster-local: "false"
  edge: "false"
  service-sync: "true"
  ingress: "none"
kind: ConfigMap
metadata:
  name: skupper-site
name
Specifies the site name.
console

Enables the skupper console, defaults to false.

Note

You must enable console and flow-collector for the console to function.

flow-collector
Enables the flow collector, defaults to false.
console-authentication
Specifies the skupper console authentication method. The options are openshift, internal, unsecured.
console-user
Username for the internal authentication option.
console-password
Password for the internal authentication option.
cluster-local
Only accept connections from within the local cluster, defaults to false.
edge
Specifies whether an edge site is created, defaults to false.
service-sync
Specifies whether the services are synchronized across the service network, defaults to true.
ingress
Specifies whether the site supports ingress. If you do not specify a value, the default ingress ('loadbalancer' on Kubernetes, 'route' on OpenShift) is enabled. This allows you to create tokens usable from remote sites.
Note

All ingress types are supported using the same parameters as the skupper CLI.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.