Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 4. Project Management

4.1. Pod Configurations
Copier lien

4.1.1. Description of Function
Copier lien

Display the Pod configurations of pods in an OpenShift cluster. Depending on the endpoint of the request, you can list the Pod configurations for all the pods in an environment, all the pods in a namespace, or a specific Pod configuration in a namespace.

4.1.2. Listing Configurations for All Pods in an Environment
Copier lien

4.1.2.1. Request Breakdown
Copier lien

Listing all the pods in an environment requires one request:

  1. A GET request to the pods resource.

The GET request returns the PodList, listing the details of all pods in the environment.

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/api/v1/pods
Copy to Clipboard Toggle word wrap

4.1.3. Listing All Pods in a Namespace
Copier lien

4.1.3.1. Request Breakdown
Copier lien

Listing all the pods in a namespace requires one request:

  1. A GET request to the pods subresource of the namespace.

The GET request returns the PodList, listing the details of all pods in the namespace.

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/api/v1/namespaces/{$PROJECT}/pods
Copy to Clipboard Toggle word wrap

4.1.4. Listing a Specific Pod Configuration in a Namespace
Copier lien

4.1.4.1. Request Breakdown
Copier lien

Listing a specific pod configuration requires one request:

  1. A GET request to the pod name in the pods subresource of the namespace.

The GET request returns the Pod configuration for the specified pod.

4.1.4.2. GET Request to Return Specific Pod Configuration
Copier lien

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/api/v1/namespaces/{$PROJECT}/pods/{$POD}
Copy to Clipboard Toggle word wrap

4.2. Idle
Copier lien

4.2.1. Description of Function
Copier lien

Idling discovers the scalable resources (such as deployment configurations and replication controllers) associated with a series of services by examining the endpoints of the service. Each service is then marked as idled, the associated resources are recorded, and the resources are scaled down to zero replicas.

Upon receiving network traffic, the services (and any associated routes) will "wake up" the associated resources by scaling them back up to their previous scale.

4.2.2. Idling a DeploymentConfig
Copier lien

4.2.2.1. Request Breakdown
Copier lien

Idling consists of a series of requests:

  1. A GET request to the endpoint name of the endpoints subresource of the namespace to discover corresponding pods.
  2. A GET request to each pod name in the pods subresource to discover the owner reference (deploymentconfig or replicationcontroller) for that pod.
  3. A GET request to the referenced owner name (deploymentconfig or replicationcontroller) to discover if that referenced owner has an owner reference.
  4. A GET request to the scale subresource for all referenced deploymentconfig or replicationcontroller objects to discover the replica value for the resource.
  5. A PATCH request with updated annotations, including idle start time and corresponding owner reference, to each endpoint name in the endpoint subresource of the namespace.
  6. A PUT request with updated annotations for the idle time and previous scale to the endpoint owner name (deploymentconfig or replicationcontroller) to set the replicas to 0.

Idling an endpoint requires a PATCH request to the endpoint, and a PUT request to the referenced owner of the resources. GET requests 1-3 discover the pods corresponding to the endpoint, the owner resource of the pods, and then discover if that owner resource is owned by another resource.

GET request 4 is optional as the replica value for the resource is in the configuration returned in a previous GET request; however, returning the scale subresource can simplify the process of retrieving the replica value.

The PATCH request adds annotations to the endpoint that include the time in which the resource is considered idle, and an owner reference so that the owner resource is scaled accordingly when a service receives traffic. The PUT request to the owner resource includes the same idle time annotation as the endpoint, the previous replica value of the resource to scale to when unidled, and replaces the replica value to 0 to idle the resource.

Expand
Table 4.1. Annotations for Determining Resource Owner
AnnotationDescription

kubernetes.io/created-by

Owner reference for Kubernetes objects.

openshift.io/deployment-config.name

Owner reference for resource belonging to a deploymentconfig.

Expand
Table 4.2. Annotations for Endpoint
AnnotationDescription

idling.alpha.openshift.io/idled-at

Indicates the time at which the resource is considered idle.

idling.alpha.openshift.io/unidle-targets

References the owner resource that the endpoint will unidle.

Expand
Table 4.3. Annotations for Idling Owner Resource
AnnotationDescription

idling.alpha.openshift.io/idled-at

Indicates the time at which the resource is considered idle.

idling.alpha.openshift.io/previous-scale

Indicates the previous scale of the resource prior to idle. When the endpoint receives traffic, the resource will scale to this value.

4.2.2.2. GET Request to Return endpoint
Copier lien

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml \
-H "Content-Type: application/yaml" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/api/v1/namespaces/{$PROJECT}/endpoints/{$ENDPOINT}
Copy to Clipboard Toggle word wrap

Response Body Snippet 

...
subsets:
- addresses:
  - ip: 192.0.2.1
    nodeName: {$OPENSHIFT_NODE_URL}
    targetRef:
      kind: Pod
      name: {$POD1}
      namespace: {$PROJECT}
      resourceVersion: "213472"
      uid: 6acc03a4-41cd-11e7-a37b-1418776f4b43
  - ip: 192.0.2.2
    nodeName: {$OPENSHIFT_NODE_URL}
    targetRef:
      kind: Pod
      name: {$POD2}
      namespace: {$PROJECT}
      resourceVersion: "213472"
      uid: 6acc02e0-41cd-11e7-a37b-1418776f4b43
...
Copy to Clipboard Toggle word wrap

The request returns two pods corresponding to the endpoint.

4.2.2.3. GET Request to Return pod Owner
Copier lien

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml \
-H "Content-Type: application/yaml" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/api/v1/namespaces/{$PROJECT}/pods/{$POD1}
Copy to Clipboard Toggle word wrap

Response Body Snippet 

...
kind: Pod
metadata:
  annotations:
    kubernetes.io/created-by: |
      {"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicationController","namespace":"{$PROJECT}","name":"{$REPLICATIONCONTROLLER}","uid":"e45f3d69-3b9a-11e7-a37b-1418776f4b43","apiVersion":"v1","resourceVersion":"213449"}}
    openshift.io/deployment-config.latest-version: "1"
    openshift.io/deployment-config.name: {$DEPLOYMENTCONFIG}
    openshift.io/deployment.name: {$DEPLOYMENT}
    openshift.io/scc: restricted
...
Copy to Clipboard Toggle word wrap

The pod owner is discovered from the kubernetes.io/created-by: and the openshift.io/deployment-config.name: annotations. The pod in this example has two owners: {$REPLICATIONCONTROLLER} and {$DEPLOYMENTCONFIG}.

For the purposes of the example, {$POD2} has the same owners.

4.2.2.4. GET Request to Return replicationcontroller Owner
Copier lien

Request Header 

curl -k -v \
-X GET \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/api/v1/namespaces/{$PROJECT}/replicationcontrollers/{$REPLICATIONCONTROLLER}
Copy to Clipboard Toggle word wrap

Response Body Snippet 

...
kind: ReplicationController
metadata:
  annotations:
    openshift.io/deployer-pod.name: {$DEPLOYER_POD}
    openshift.io/deployment-config.latest-version: "1"
    openshift.io/deployment-config.name: {$DEPLOYMENTCONFIG}
...
Copy to Clipboard Toggle word wrap

The replication owner is discovered with the openshift.io/deployment-config.name: annotation. The replication controller in this example is also owned by {$DEPLOYMENTCONFIG}.

4.2.2.5. GET Request to Return the deploymentconfig Owner
Copier lien

Request Header 

curl -k -v \
-X GET \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENTCONFIG}
Copy to Clipboard Toggle word wrap

Response Body Snippet 

...
kind: DeploymentConfig
metadata:
  annotations:
    openshift.io/generated-by: OpenShiftWebConsole
...
Copy to Clipboard Toggle word wrap

The returned deploymentconfig shows no owner, confirming that {$DEPLOYMENTCONFIG} is the sole owner of {$POD1} and {$POD2}.

4.2.2.6. GET Request to Return Scale
Copier lien

Request Header 

curl -k -v \
-X PUT \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENTCONFIG}/scale
Copy to Clipboard Toggle word wrap

Response Body Snippet 

...
kind: Scale
spec:
  replicas: 2
...
Copy to Clipboard Toggle word wrap

The deploymentconfig has a replica value of 2. This will be used when updating the deploymentconfig to idle the resources.

4.2.2.7. PATCH Request to Update endpoint
Copier lien

Note

PATCH requests require JSON formatting.

Request Header 

curl -k -v \
-X PATCH \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/json" \
-H "Content-Type: text/strategic-merge-patch+json" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/api/v1/namespaces/{$PROJECT}/endpoints/{$ENDPOINT}
Copy to Clipboard Toggle word wrap

Request Body 

{
  "metadata":
    "annotations": {
      "idling.alpha.openshift.io/idled-at": "2017-06-21T04:18:54Z",
      "idling.alpha.openshift.io/unidle-targets": "[{\"kind\":\"DeploymentConfig\",\"name\":\"{$DEPLOYMENTCONFIG}\",\"replicas\":2}]"
    }
}
Copy to Clipboard Toggle word wrap

The idling.alpha.openshift.io/idled-at: annotation indicates the time at which the endpoint is considered idled. The same annotation is used for the owner in the next step.
The idling.alpha.openshift.io/unidle-targets: annotation indicates that the endpoint will unidle the owner.

4.2.2.8. PUT Request to Update the deploymentconfig
Copier lien

Request Header 

curl -k -v \
-X PUT \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENTCONFIG}
Copy to Clipboard Toggle word wrap

Request Body Snippet 

...
kind: DeploymentConfig
metadata:
  annotations:
    idling.alpha.openshift.io/idled-at: 2017-06-21T04:18:54Z
    idling.alpha.openshift.io/previous-scale: "2"
    openshift.io/generated-by: OpenShiftWebConsole
...
spec:
  replicas: 0
...
Copy to Clipboard Toggle word wrap

The PUT request uses the deploymentconfig returned in a previous request, modified with the following:

  • The idling.alpha.openshift.io/idled-at: annotation is added to indicate the time at which the endpoint is considered idled.
  • The idling.alpha.openshift.io/previous-scale: annotation is added, using the value from the previous scale request. When the endpoint is unidled, this value will determine the number of replicas to scale.
  • The replicas value is modified to 0.

4.3. Rollback
Copier lien

4.3.1. Description of Function
Copier lien

Revert an application back to a previous deployment.

When you run this command your deployment configuration will be updated to match a previous deployment. By default only the pod and container configuration will be changed and scaling or trigger settings will be left as-is. Note that environment variables and volumes are included in rollbacks; if you have recently updated security credentials in your environment your previous deployment may not have the correct values.

Any image triggers present in the rolled back configuration will be disabled with a warning. This is to help prevent your rolled back deployment from being replaced by a triggered deployment soon after your rollback.

Any version of the deploymentconfig can be used for the rollback request. Rolling back a deployment creates a new deployment version. All deployment reversions use rollback requests, whether rolling the version back or forward.

4.3.2. Rolling Back a Deployment
Copier lien

4.3.2.1. Request Breakdown
Copier lien

Deployment rollback consists of two requests:

  1. A POST request to the rollback subresource of the deployment.
  2. A PUT request to the deployment name in the deploymentconfig subresource of the namespace.

The POST request body specifies which elements of the deployment configuration version spec to be included in the returned deploymentconfig. The request returns a new deploymentconfig that represents the rollback state and can be used verbatim in the request body of the PUT request.

The PUT request body sends the returned deploymentconfig configuration to the deployment name in the subresource. This triggers a new deployment that effectively rolls back the deployment to the version specified in the returned deploymentconfig.

4.3.2.2. POST Request to Return deploymentconfig
Copier lien

Request Header 

curl -k -v \
-X POST  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENT}/rollback
Copy to Clipboard Toggle word wrap

Request Body 

apiVersion: v1
kind: DeploymentConfigRollback
name: {$DEPLOYMENT}
spec:
  from:
    name: {$DEPLOYMENT}-{$VERSION}
  includeTriggers: false
  includeTemplate: true
  includeReplicationMeta: false
  includeStrategy: false
Copy to Clipboard Toggle word wrap
Expand
Table 4.4. Field Descriptions
Field NameDescriptionRequiredType

includeTriggers

Returns the triggers parameters of the specified deployment version for rollback

True

Boolean

includeTemplate

Returns the template parameters of the specified deployment version for rollback

True

Boolean

includeReplicationMeta

Returns the replicas and selector parameters of the specified deployment version for rollback

True

Boolean

includeStrategy

Returns the strategy parameters of the specified deployment version for rollback

True

Boolean

Request Header 

curl -k -v \
-X PUT \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENT}
Copy to Clipboard Toggle word wrap

Request Body

Use the response body returned by the POST request as the request body. No changes are necessary.

4.4. Scale
Copier lien

4.4.1. Description of Function
Copier lien

Set a new size for a deployment, replicationcontroller, or job resources:

  • deploymentconfig: Modify the number of replica pods for the deployment.
  • replicationcontroller: Modify the number of replicas maintained by a replication controller in a deployment.
  • job: Modify the number of pod replicas running in parallel, executing a job.

4.4.2. Scaling a Deployment
Copier lien

4.4.2.1. Request Breakdown
Copier lien

Scaling a deployment consists of two requests:

  1. A GET request to the scale subresource of the deployment.
  2. A PUT request with an updated replicas value to the scale subresource of the deployment.

The GET request returns the Scale configuration.
The GET request is optional if an updated Scale configuration can otherwise be provided for the PUT request.

Update the spec: replicas parameter in the Scale configuration. Send the configuration as the request body in a PUT request to the scale subresource of the deployment.

4.4.2.2. GET Request to Scale Deployment
Copier lien

Request Header 

curl -k -v \
-X GET \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENT}/scale
Copy to Clipboard Toggle word wrap

4.4.2.3. PUT Request to Scale Deployment
Copier lien

Request Header 

curl -k -v
curl -k -v \
-X PUT \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENT}/scale
Copy to Clipboard Toggle word wrap

Request Body Snippet 

...
spec:
  replicas: 3
...
Copy to Clipboard Toggle word wrap

4.4.3. Scaling a Replication Controller
Copier lien

4.4.3.1. Request Breakdown
Copier lien

Scaling a replication controller consists of two requests:

  1. A GET request to the deployment name and version in the replicationcontrollers subresource of the namespace.
  2. A PUT request with an updated replicas value to the same deployment in the replicationcontrollers of the namespace.

The GET request returns the ReplicationController configuration.
The GET request is optional if an updated ReplicationController configuration can otherwise be provided for the PUT request. The ReplicationController configuration includes an encoded deploymentconfig for the deployment being scaled.

Update the spec: replicas parameter in the ReplicationController configuration. Send the configuration as the request body in a PUT request to the deployment replicationcontrollers resource.

4.4.3.2. GET Request for Deployment Replication Controller
Copier lien

Request Header 

curl -k -v \
-X GET \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
GET {$OCP_CLUSTER}/api/v1/namespaces/{$PROJECT}/replicationcontrollers/{$DEPLOYMENT}-{$VERSION}
Copy to Clipboard Toggle word wrap

4.4.3.3. PUT Request to Scale Replication Controller
Copier lien

Request Header 

curl -k -v \
-X PUT \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/api/v1/namespaces/{$PROJECT}/replicationcontrollers/{$DEPLOYMENT}-{$VERSION}
Copy to Clipboard Toggle word wrap

Request Body Snippet 

...
spec:
  replicas: 3
...
Copy to Clipboard Toggle word wrap

4.4.4. Scaling a Job
Copier lien

4.4.4.1. Request Breakdown
Copier lien

Scaling a job consists of two requests:

  1. A GET request to the job name in the jobs subresource of the namespace .
  2. A PUT request with an updated parallelism value to the job name in the jobs subresource of the namespace .

The GET request returns a Job configuration.
The GET request is optional if an updated Job configuration can otherwise be provided for the PUT request.

Update the spec: parallelism parameter in the Job configuration. Send the configuration as the request body in a PUT request to the deployment jobs subresource.

4.4.4.2. GET Request for Deployment Job
Copier lien

Request Header 

curl -k -v \
-X GET \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/apis/batch/v1/namespaces/{$PROJECT}/jobs/{$JOB}
Copy to Clipboard Toggle word wrap

4.4.4.3. PUT Request to Scale Job
Copier lien

Request Header 

curl -k -v \
-X PUT \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/apis/batch/v1/namespaces/{$PROJECT}/jobs/{$JOB}
Copy to Clipboard Toggle word wrap

Request Body Snippet 

...
spec:
  parallelism: 3
...
Copy to Clipboard Toggle word wrap

4.5. Routes
Copier lien

4.5.1. Description of Resource
Copier lien

A route allows developers to expose services through an HTTP(S) aware load balancing and proxy layer via a public DNS entry. The route may further specify TLS options and a certificate, or specify a public CNAME that the router should also accept for HTTP and HTTPS traffic. An administrator typically configures their router to be visible outside the cluster firewall, and may also add additional security, caching, or traffic controls on the service content. Routers usually talk directly to the service endpoints.

Once a route is created, the host field may not be changed. Generally, routers use the oldest route with a given host when resolving conflicts.

Routers are subject to additional customization and may support additional controls via the annotations field.

Because administrators may configure multiple routers, the route status field is used to return information to clients about the names and states of the route under each router. If a client chooses a duplicate name, for instance, the route status conditions are used to indicate the route cannot be chosen.

See the Architecture Guide and the Developer Guide for more information on routes, and the REST API Guide for complete field descriptions.

4.5.2. Creating a New Route
Copier lien

4.5.2.1. Request Breakdown
Copier lien

Creating a new route requires one request:

  1. A POST request to the routes subresource of the namespace.

The POST request uses a Route configuration in the request body.
The following request example uses the minimum required fields to expose a service with an insecure route.

4.5.2.2. POST Request to Create a New Route
Copier lien

Request Header 

curl -k -v \
-X POST \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/routes
Copy to Clipboard Toggle word wrap

Request Body 

apiVersion: v1
kind: Route
metadata:
  name: {$ROUTE_NAME}
spec:
  to:
    kind: Service
    name: {$SERVICE_NAME}
Copy to Clipboard Toggle word wrap
Expand
Table 4.5. Route metadata Fields
Field.subfieldDescriptionType

labels.app

Map of string keys and values that can be used to organize and categorize (scope and select) objects. Used primarily for router sharding. May match selectors of replication controllers and services.

projectlabel

name

Name of the route.

routename

Expand
Table 4.6. Route spec Fields
Field.subfieldDescriptionType

host

Host is an optional alias/DNS that points to the service. If not specified, a route name will typically be automatically chosen. Must follow DNS952 subdomain conventions.

route-project.router.default.svc.cluster.local

port.targetPort

If specified, the port to be used by the router. Most routers will use all endpoints exposed by the service by default - set this value to instruct routers which port to use.

8080-tcp

to.name

Name of the service/target used for the route.

servicename

to.weight

Weight as an integer between 1 and 256 that specifies the target’s relative weight against other target. reference objects

1

alternateBackends.name

Name of an alternate service/target that is being referred to.

altservice

alternateBackends.weight

Weight as an integer between 1 and 256 that specifies the target’s relative weight against other target.

1

tls.termination

The tls field provides the ability to configure certificates and termination for the route. Options are 'edge', 'passthrough', 'reencrypt'.

edge

wildcardPolicy

Wildcard policy, if any, for the route. Currently only 'Subdomain' or 'None' is allowed.

Subdomain

4.5.3. Listing All Service Configurations in an Environment
Copier lien

4.5.3.1. Request Breakdown
Copier lien

Listing the configurations for all routes in an environment requires one request:

  1. A GET request to the routes resource.

The GET request returns the RouteList, listing the details of all routes in the environment.

Request Header 

curl -k -v \
-X GET \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/routes
Copy to Clipboard Toggle word wrap

4.5.4. Listing All Service Configurations in a Namespace
Copier lien

4.5.4.1. Request Breakdown
Copier lien

Listing the configurations for all services in a namespace requires one request:

  1. A GET request to the routes subresource of the namespace.

The GET request returns the RouteList, listing the details of all routes in the namespace.

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/routes
Copy to Clipboard Toggle word wrap

4.5.5. Listing a Specific Route Configuration in a Namespace
Copier lien

4.5.5.1. Request Breakdown
Copier lien

Listing a specific Route configuration requires one request:

  1. A GET request to the route name in the routes subresource of the namespace.

The GET request returns the Route configuration for the specified route.

4.5.5.2. GET Request to Return Specific Route Configuration
Copier lien

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/routes/{$ROUTE}
Copy to Clipboard Toggle word wrap

4.5.6. Updating a Route Configuration
Copier lien

Updating a Route configuration requires two requests:

  1. A GET request to the route name in the routes subresource of the namespace.
  2. A PATCH request with updated field values to the route name in the routes subresource of the namespace.

The GET request is optional as the PATCH request body is not determined by the returned configuration, however it can be useful for preparing the PATCH request body.

4.5.6.1. PATCH Request to Update Route Configuration
Copier lien

Note

PATCH requests require JSON formatting.

The following PATCH request example adds an alternate service to the route and updates the original service with an equal weight:

Request Header 

curl -k -v \
-X PATCH \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/json" \
-H "Content-Type: text/strategic-merge-patch+json" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/
routes/{$ROUTE}
Copy to Clipboard Toggle word wrap

Request Body 

{
  "spec": {
     "to": {
      "weight": 1
     },
     "alternateBackends": [
       {
        "kind": "Service",
        "name": "{$ALT_SERVICE}",
        "weight": 1
       }
    ]
  }
}
Copy to Clipboard Toggle word wrap

4.5.7. Deleting a Route
Copier lien

4.5.7.1. Request Breakdown
Copier lien

Deleting a route requires one request:

  1. A DELETE request to the route name in the routes subresource of the namespace.

The DELETE request returns a code: 200 and the route is deleted.

4.5.7.2. DELETE Request to Delete a Route
Copier lien

Request Header 

curl -k -v \
-X DELETE  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/routes/{$ROUTE}
Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat