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

Chapter 21. Using the Skupper console


You can use the Skupper console to monitor and troubleshoot your application network. The console provides a visual overview of the sites, links, services, and communication metrics.

Prerequisites

  • Access to an Kubernetes cluster with Network Observer installed.
  • A site is created in a namespace

Procedure

  1. Change context to the site namespace.
  2. If you are using the OpenShift console:

    1. Navigate to Operators Installed Operators.
    2. Choose Red Hat Service Interconnect Network Observer Operator from the list of available Operators, and then click Create Instance.
  3. If you are not using the OpenShift console:

    1. Create a file named network-observer.yaml with the following CR:

      apiVersion: observability.skupper.io/v2alpha1
      kind: NetworkObserver
      metadata:
        name: networkobserver-sample
        namespace: west
      spec: {}
      Copy to Clipboard Toggle word wrap

      Change the namespace value to match the site namespace.

  4. Apply the CR YAML:

    $ kubectl apply -f network-observer.yaml
    Copy to Clipboard Toggle word wrap
  5. Determine the console URL:

    kubectl get --namespace west -o jsonpath="{.spec.host}" route networkobserver-sample-network-observer
    Copy to Clipboard Toggle word wrap
  6. Navigate to the console.

21.1. Configuring the Network observer

Currently the primary purpose of the Network Observer is to provide a console for monitoring your application network. This section describes advanced configuration.

  1. Change context to a site namespace.
  2. Apply a CR to create the Network Observer instance

    The following CR shows the supported parameters that you can use to configure the Network observer instance:

    apiVersion: observability.skupper.io/v2alpha1
    kind: NetworkObserver
    metadata:
      name: networkobserver-sample
      namespace: west
    spec:
      # Resource requests and limits
      resources:
        requests:
          cpu: "250m"
          memory: "4Gi"
        limits:
          cpu: "1"
          memory: "8Gi"
    
      # Authentication strategies
      auth:
        # strategy is one of none, basic, or openshift
        strategy: "openshift"
        openshift:
          # createCookieSecret -
          # for the openshift oauth2 proxy.
          createCookieSecret: true
          # cookieSecretName name of the session cookie secret.
          cookieSecretName: ""
          # Service account for openshift auth
          serviceAccount:
            create: true
            nameOverride: ""
    Copy to Clipboard Toggle word wrap

    See the table below for explanation of the parameters.

  3. Verify the configuration, enter:

    oc describe networkobserver networkobserver-sample -n west
    Copy to Clipboard Toggle word wrap

    Note that the parameters listed in output, not related to the CR above, are not configurable.

Parameters reference

The following table describes the configuration parameters:

Expand
ParameterTypeDescription / Implications

resources.requests.cpu

String

The minimum CPU guaranteed to the Network observer. Increase this if the console feels sluggish under high network load.

resources.requests.memory

String

The initial memory allocation. 4Gi is the recommended minimum for medium-sized networks.

resources.limits.cpu

String

The maximum CPU the Network observer can consume.

resources.limits.memory

String

The upper bound of memory.

If memory usage exceeds this limit, the pod is terminated due to insufficient memory.

auth.strategy

String

Defines how users log in. Options: none (no auth), basic (username/password), or openshift (default OAuth2 proxy).

auth.openshift.createCookieSecret

Boolean

When true (default), the operator automatically generates a secret for the OAuth2 session cookie. Set to false if providing a manual secret.

auth.openshift.serviceAccount.create

Boolean

When true (default), the operator automatically creates a ServiceAccount with the necessary permissions for OpenShift authentication.

Troubleshooting

If you are concerned about Network Observer resources, consider using standard techniques to monitor those resources. The following example demonstrates how to configure a Prometheus alert that triggers when memory usage exceeds 90% of the defined limit.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: network-observer-memory-alert
  namespace: west
spec:
  groups:
  - name: network-observer.rules
    rules:
    - alert: NetworkObserverHighMemory
      expr: |
        (container_memory_working_set_bytes{namespace="west", container="network-observer"}
        /
        kube_pod_container_resource_limits{namespace="west", container="network-observer", resource="memory"}) > 0.9
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Network Observer pod in namespace {{ $labels.namespace }} is using > 90% of its memory limit."
        description: "Pod {{ $labels.pod }} is currently using {{ $value | humanizePercentage }} of its memory limit."
Copy to Clipboard Toggle word wrap
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2026 Red Hat
맨 위로 이동