Skip to content
This repository was archived by the owner on Sep 4, 2020. It is now read-only.

Latest commit

 

History

History
140 lines (110 loc) · 5.49 KB

scopes.md

File metadata and controls

140 lines (110 loc) · 5.49 KB

Scopes

Scopes are used to logically group components within an application.

Application scopes are used to logically group components together by providing application boundaries that represent common group behaviors and/or dependencies. Scopes are not mutually exclusive: a given component can belong to multiple application scope instances at the same time. Once installed to your Rudr runtime, a scope can be used (and reused) across any number of application configurations. In terms of implementation details, scopes are Rudr-defined Kubernetes CRDs.

Scopes are assigned to component workloads by an application operator.

scope schematic comic

Currently, Rudr supports the following scope types:

An application operator configures and assigns scope instances to component workloads of an application in the ApplicationConfiguration file. For example, here's a custom configuration of the Rudr health scope type:

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: my-health-scope
spec:
  scopes:
    - name: health
      type: core.oam.dev/v1alpha1.HealthScope
      properties:
        - name: probe-method
          value: "kube-get"
        - name: probe-endpoint
          value: ".status"
        - name: probe-timeout
          value: 30
        - name: probe-interval
          value: 60
        - name: failure-rate-threshold
          value: 0
        - name: healthy-rate-threshold
          value: 100.0
        - name: healthThresholdPercentage
          value: 100.0

And here's how a component would be added to that scope within the application configuration file:

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: first-app
spec:
  components:
    - name: helloworld-python-v1
      instanceName: first-app-helloworld-python-v1
      parameterValues:
        - name: target
          value: Rudr
        - name: port
          value: "9999"
      traits:
        - name: ingress
        properties:
          hostname: example.com
          path: /
          servicePort: 9999
      applicationScopes:
        - my-health-scope

For more on using specific scopes, refer to the sections below.

Supported scopes

Here's how to get info on the scopes supported on your Rudr installation.

List supported scope types:

$ kubectl get scopes

Show the schema details of a scope instance:

$ kubectl get <scope-type> <scope-name> -o yaml

... where <scope-type> is one of the Rudr-supported scopes types (per kubectl get scopes), and <scope-name> is the name of a particular scope configuration instance. For example: kubectl get health my-health-scope -o yaml.

Health scope

You can use the HealthScope controller to periodically check the aggregate health of components within your application. For a full walkthrough, see Health Scope Controller

Installation

Use Helm 3 to install the Rudr HealthScope:

helm install healthscope ./charts/healthscope

Properties

Name Description Allowable values Required Default
probe-method The method to probe the components, e.g. 'httpGet'. string
probe-endpoint The endpoint to probe from the components, e.g. '/v1/health'. string
probe-timeout The amount of time in seconds to wait when receiving a response before marked failure. int
probe-interval The amount of time in seconds between probing tries. int
failure-rate-threshold If the rate of failure of total probe results is above this threshold, declared 'failed'. double
healthy-rate-threshold If the rate of healthy of total probe results is above this threshold, declared 'healthy'. double
healthThresholdPercentage The % of healthy components required to upgrade scope. double
requiredHealthyComponents Comma-separated list of names of the components required to be healthy for the scope to be health. string

Here's an example of a health scope configuration. Once installed (kubectl apply -f <health-scope-config>.yaml) you would attach this to a component within the application configuration, similar to this example:

# Example component scope assignment
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: first-app
spec:
  components:
    - name: helloworld-python-v1
      instanceName: first-app-helloworld-python-v1
      parameterValues:
        # ...
      traits:
        # ...  
      applicationScopes:
        - my-health-scope

Once you deploy that application configuration, you can verify the health scope instance was created:

kubectl get health

And get further details about it with kubectl get health my-health-scope -o yaml.