Una interfaz de programación de aplicaciones (API) define los recursos en una aplicación que están disponibles a través de la interacción remota con la aplicación. La API de OpenShift se basa en la API de Kubernetes, con una capa de API específicas de OpenShift que brindan funcionalidad adicional.Los ejemplos de diferentes API específicas de OpenShift incluyen routes, buildconfigsy deploymentconfigs.
Debido a las capacidades adicionales de OpenShift, los recursos de Kubernetes no siempre son compatibles con los recursos de OpenShift. Cuando realiza la transición de un entorno de Kubernetes a un entorno de OpenShift, OpenShift adoptará sus recursos de la API de Kubernetes sin problemas, pero no al revés.
Puede explorar la API desde la línea de comandos para aprender a definir recursos de forma declarativa mediante YAML.
Tabla de Contenidos
Explore las API de OpenShift
OpenShift incluye documentación integrada de forma predeterminada. Los siguientes son ejemplos de comandos que se pueden usar para ver su documentación API sin acceso a Internet:
$ oc api-resources
usar grep Filtre los resultados para que pueda ver las diferencias entre la información de la versión de la API deploymentconfigs (recursos de OpenShift) y deployments (un recurso de Kubernetes):
$ oc api-resources | grep deployment
deployments deploy apps/v1 true Deployment
deploymentconfigs dc apps.openshift.io/v1 true DeploymentConfig
[ Download the Kubernetes glossary cheat sheet. ]
Este NAMESPACED Las columnas en el resultado a continuación describen algunos recursos con valores trueEstos recursos se pueden restringir a un espacio de nombres específico.recursos de valor false Existe en todos los espacios de nombres, reemplazando las restricciones de espacios de nombres.
$ oc api-resources | head -n 5
NAME SHORTNAMES APIVERSION NAMESPACED KIND
bindings v1 true Binding
componentstatuses cs v1 false ComponentStatus
configmaps cm v1 true ConfigMap
endpoints ep v1 true Endpoints
La versión de la API es especialmente importante cuando trabaja con archivos YAML. Conocer la versión ayuda a evitar los mensajes de error de la API. Su versión de YAML debe estar en contra de la versión proporcionada actualmente por la API. Para ver la versión de su API, escriba:
$ oc api-versions
Por ejemplo, el siguiente ejemplo muestra la versión de API requerida en el archivo YAML de restricciones de contexto de seguridad (SCC), que coincide con la versión de API disponible en mi instalación de OpenShift. Es importante realizar un seguimiento de esto, ya que las versiones de la API pueden actualizarse en el futuro. Si v2 es la única versión de API disponible y su archivo YAML se trata de v1, sus recursos no funcionarán como se esperaba.
---
kind: SecurityContextConstraints
apiVersion: security.openshift.io/v1
metadata:
name: scc-admin
...
usar oc api-versions Obtenga la versión de la API. P.ej:
$ oc api-versions | grep security.openshift
security.openshift.io/v1
precaución security.openshift separados por un punto. La notación de puntos le permite concentrarse en un parámetro o propiedad específica de un recurso específico. P.ej, oc explain pod.spec Muestra los parámetros que puede usar en la especificación del pod. Para obtener detalles adicionales sobre el contenedor y las diferentes propiedades que puede aplicar, use más puntos para recorrer la jerarquía (por ejemplo, oc explain pod.spec.containers).
Explora la API
Para ver el contenido de la API en detalle, utilice oc explain:
$ oc explain
$ oc explain --recursive
Según la información en oc explainpuede definir recursos en declaraciones YAML.
[ Get this complimentary eBook from Red Hat: Managing your Kubernetes clusters for dummies. ]
Explore la especificación del módulo de API
El siguiente YAML muestra un escribe especificación vaina contiene una Especificación parte:
---
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: alpine
image: alpine:3.9
command:
- "sleep"
- "3600"
…
Para obtener más información sobre la especificación de un tipo específico (en este caso, pod), oc explain es el mejor orden.
Este comando muestra todas las diferentes propiedades y descripciones que puede usar en el pod:
$ oc explain pod.spec
---
KIND: Pod
VERSION: v1
RESOURCE: spec
Esto proporciona todos los parámetros y propiedades que puede aplicar en la especificación del pod.Si es nuevo en Kubernetes u OpenShift y no puede diferenciar entre pods y contenedores, entonces oc explain pod.spec y oc explain pod.spec.containers puede revelarte la verdad. Aquí hay un ejemplo:
$ oc explain pod.spec.containers
---
KIND: Pod
VERSION: v1
RESOURCE: containers <[]Object>
DESCRIPTION:
List of containers belonging to the pod. Containers
cannot currently be added or removed. There must be at
least one container in a Pod. Cannot be updated.
A single application container that you want to run
within a pod.
FIELDS:
args <[]string>
Arguments to the entrypoint. The docker image's CMD is
used if this is not provided. Variable references $(VAR_NAME)
are expanded using the container's environment. If a variable
cannot be resolved, the reference in the input string will be
unchanged. Double $$ are reduced to a single $, which allows
for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will
produce the string literal "$(VAR_NAME)". Escaped references
will never be expanded, regardless of whether the variable
exists or not. Cannot be updated. More info:
define-command-argument-container/#running-a-command-in-a-shell
command <[]string>
Entrypoint array. Not executed within a shell. The docker
image's ENTRYPOINT is used if this is not provided. Variable
references $(VAR_NAME) are expanded using the container's
environment. If a variable cannot be resolved, the reference in
the input string will be unchanged. Double $$ are reduced to a
single $, which allows for escaping the $(VAR_NAME) syntax:
i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)".
Escaped references will never be expanded, regardless of whether
the variable exists or not. Cannot be updated. More info:
define-command-argument-container/#running-a-command-in-a-shell
env <[]Object>
List of environment variables to set in the container.
Cannot be updated.
Explora más oc explain deployment.spec y oc explain deploymentconfigs.spec Vea la diferencia entre implementación y configuración de implementación y muestre los parámetros disponibles para la implementación y la configuración de implementación.
Tenga en cuenta que uno es un recurso de Kubernetes y el otro es un recurso específico de OpenShift.
Una diferencia notable es que las implementaciones no tienen especificaciones de activación, pero las configuraciones de implementación tienen especificaciones de activación. Para ver los diferentes parámetros que se pueden definir como parte del archivo YAML declarativo en la sección de disparadores, use:
$ oc explain deploymentconfigs.spec.triggers
---
KIND: DeploymentConfig
VERSION: apps.openshift.io/v1
RESOURCE: triggers <[]Object>
DESCRIPTION:
Triggers determine how updates to a DeploymentConfig result in new
deployments. If no triggers are defined, a new deployment can only
occur as a result of an explicit client update to the
DeploymentConfig with a new LatestVersion. If null, defaults to
having a config change trigger.
DeploymentTriggerPolicy describes a policy for a single trigger
that results in a new deployment.
FIELDS:
imageChangeParams
Uso de la documentación de recursos de API en vivo
Así como Linux proporciona páginas man, OpenShift proporciona documentación definida en su API. Es importante proporcionar esta información para que pueda encontrar rápidamente la información que necesita para la administración diaria de OpenShift. Este enfoque le ahorra tiempo en entornos con espacios de aire limitados.
