OAM v1alpha2 Nuevo: equilibrio estándar y escalabilidad

Others 2020-04-01 12:05:55 views: null

Autor | Sun Jianbo (Tianyuan) expertos en tecnología Ali nube

Introducción : Espec OAM después de casi tres meses de iteraciones, v1alpha2  versión que finalmente liberado! Sobre la base de la nueva versión de OAM independiente de la plataforma Spec insistir en toda la tecnología más Kubernetes ambiente convertido, en gran medida balance de las normas y escalabilidad, mejor soporte CRD. Si usted ha escrito fuera de la plataforma del operador CRD, se puede suavizar el acceso al sistema OAM, y disfrutar de los dividendos de modelo de OAM.

Actualmente OAM ha convertido en la arquitectura de núcleo, incluyendo Ali, Microsoft, Upbond, nube armónica y otras empresas a las ofertas de acumulación de nubes. Construyeron por el "centrado en las aplicaciones" la facilidad de uso de la Kubernetes PaaS OAM; dar pleno juego a la estandarización y la escalabilidad de OAM, el núcleo OAM Controller al mismo tiempo, el rápido acceso a la capacidad existente del operador; abierto lateralmente a través de OAM múltiples módulos, deshacerse del operador original, aislados unos de otros, no podemos volver a utilizar el dilema.

A continuación Más cerca de casa, veamos v1alpha2 al final hacer lo que cambia?

Los principales cambios explicados

Con el fin de facilitar la lectura, aquí sólo muestra los cambios más importantes, hasta el punto, algunos de los detalles o el sentido ascendente OAM Spec Github repositorio prevalecen.

término Descripción

  • CRD (Custom Resource Definition): En el OAM dijo que la CRD es una descripción de recurso personalizado refiere a la definición de. K8S implementadas en el OAM puede corresponder exactamente a la CRD de K8S, en la ejecución de las no K8S, OAM comprende el CRD necesidad APIVersion / Tipo y puede verificar el campo de descripción;

  • CR (recurso personalizado), OAM CR es un ejemplo de la CRD, un recurso se describe en línea con el formato de campo de definición de CRD. K8S implementa en el OAM de los correspondientes K8S CR completamente en el logro de los no K8S, la alineación puede ser necesaria APIVersion Kind y formato de campo de definición /.

Los principales cambios en el uso de 1 Referencia definiciones del modelo de carga de trabajo, Trait y alcance

v1alpha1 manera original es la siguiente:

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: WorkloadType
metadata:
  name: OpenFaaS
  annotations:
    version: v1.0.0
    description: "OpenFaaS a Workload which can serve workload running as functions"
spec:
  group: openfaas.com
  version: v1alpha2
  names:
    kind: Function
    singular: function
    plural: functions
  workloadSettings: |
    {
      "$schema": "http://json-schema.org/draft-07/schema#",
      "type": "object",
      "required": [
        "name", "image"
      ],
      "properties": {
        "name": {
          "type": "string",
          "description": "the name to the function"
        },
        "image": {
          "type": "string",
          "description": "the docker image of the function"
        }
      }
    }

En el modelo original, el grupo / versión / tipo son campo, jsonschema comprobación de las especificaciones representado por el formato general es en realidad la CRD es similar, pero no idéntico.

El nuevo v1alpha2 cambió completamente el modelo de referencia, a través de WorkloadDefinition  TraitDefinition  ScopeDefinitionla forma de una referencia para describir la relación. Puede ser una referencia directa a un CRD, el nombre es el nombre de la CRD. Para lograr OAM no K8S de él, aquí es el nombre de un índice, se puede encontrar el archivo CRD suma de comprobación similar, compruebe el archivo contiene apiVersion y amable, y la validación del esquema correspondiente.

  • carga de trabajo
apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: containerisedworkload.core.oam.dev
spec:
  definitionRef:
    # Name of CRD. 
    name: containerisedworkload.core.oam.dev
  • Rasgo
apiVersion: core.oam.dev/v1alpha2
kind: TraitDefinition
metadata:
  name: manualscalertrait.core.oam.dev
spec:
  appliesToWorkloads:
    - containerizedworkload.core.oam.dev
  definitionRef:
    name: manualscalertrait.core.oam.dev
  • Alcance
apiVersion: core.oam.dev/v1alpha2
kind: ScopeDefinition
metadata:
  name: networkscope.core.oam.dev
spec:
  allowComponentOverlap: true
  definitionRef:
    name: networkscope.core.oam.dev

nota:

  1. Aquí para lograr OAM K8S de ella, el nombre CRD es K8S dentro del nombre, por la <plural-kind>.<group>composición. La mejor práctica es una comunidad de CRD sólo una versión que se ejecuta en el clúster, será compatible con él la mayor parte de la nueva versión, se sustituyen por una actualización en tiempo uno a la última versión. Si hay una escena 2 están presentes simultáneamente versión, el usuario puede kubectl get crd <name>seleccionar aún más la forma;

  2. Definición Esta capa no se enfrenta el usuario final, la plataforma principal para su uso, para su aplicación no K8S, si existe una pluralidad de escenas versión, la plataforma de implementación OAM a un usuario final puede seleccionar una versión diferente de la serie.

Directamente en cambios importantes K8S CR 2 de componentes como ejemplos y Trait

La carga de trabajo y el nivel Rasgo manera original, que son sólo una parte de la especificación fuera de CR, respectivamente, en workloadSettingse propertiescampo.

A pesar de esta manera puede "deriva" K8S CR, pero no es propicio para el acceso en el CRD K8S ecológica, necesidad de cambiar formatos redefinido especificación de nuevo.

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: rediscluster
spec:
  workloadType: cache.crossplane.io/v1alpha1.RedisCluster
  workloadSettings:
    engineVersion: 1.0
    region: cn

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: custom-single-app
  annotations:
    version: v1.0.0
    description: "Customized version of single-app"
spec:
  variables:
  components:
    - componentName: frontend
      instanceName: web-front-end
      parameterValues:
      traits:
        - name: manual-scaler
          properties:
            replicaCount: 5

Ahora incrustado directamente CR manera, se puede ver en workloady traitdescrito a continuación es un CR campo completo.

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: example-server
spec:
  prameters:
    - name: xxx
      fieldPaths: 
        - "spec.osType"
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: Server
    spec:
      osType: linux
      containers:
      - name: my-cool-server
        image:
          name: example/very-cool-server:1.0.0
        ports:
        - name: http
          value: 8080
        env:
        - name: CACHE_SECRET

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: cool-example
spec:
  components:
  - componentName: example-server
    traits:
    - trait:
        apiVersion: core.oam.dev/v1alpha2
        kind: ManualScalerTrait
        spec:
          replicaCount: 3

La ventaja es obvia:

  1. Puede fácilmente K8S sistema de acoplamiento en el CRD convencional, incluso K8S nativa Deployment(como un acceso de carga de trabajo de encargo) y otros recursos;
  2. campo K8S CR define el nivel de maduro, completo de análisis y validación también denominados sistema de CRD.

Aquí observamos que los siguientes rasgos es []trait{CR}no la []CR  estructura, más de una capa de aparentemente inútil traitde campo, principalmente por las siguientes dos razones:

  • En esta dimensión para el rasgo subsiguiente hacer dejar espacio para la expansión, como la posible disposición ( ordering) y así sucesivamente.
  • sistema no K8S en esta capa puede no ser estrictamente de acuerdo con el texto del CR, completamente personalizable, no se une K8S descripción de formato.

3 principales parámetros de transmisión utilizadas cambios jsonPath reemplazar el original de fromParam

I + D puede dejar un campo para la operación y mantenimiento de cubierta , que ha sido un OAM función muy importante.

Esto se refleja en el flujo de la OAM Spec: desarrollo de componentes en el interior del parámetro, operación y mantenimiento se define para cubrir los parámetros correspondientes parameterValue AppConfig interior.

El paso de parámetros inicial, hay un campo en la parte posterior de cada fromParam  campo, el apoyo a un esquema personalizado, de esta manera claramente no puede cubrir todos los escenarios:

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: rediscluster
spec:
  workloadType: cache.crossplane.io/v1alpha1.RedisCluster
  parameters:
  - name: engineVersion
    type: string
  workloadSettings:
    - name: engineVersion
      type: string
      fromParam: engineVersion

Después habíamos propuesto esquema de un ejemplo:

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: rediscluster
spec:
  workloadType: cache.crossplane.io/v1alpha1.RedisCluster
  parameters:
  - name: engineVersion
    type: string
  workloadSettings:
    engineVersion: "[fromParam(engineVersion)]"

El mayor problema de este programa es estática IAD (Infraestructura como de datos) que funciona se han añadido dinámica de entender y utilizar trae complejidad.

Después de mucha discusión, se describe un nuevo programa en la posición de parámetros a ser inyectado en forma de JsonPath, en la comprensión del usuario para garantizar la AppConfig es estática.

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: example-server
spec:
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: Server
    spec:
      containers:
      - name: my-cool-server
        image:
          name: example/very-cool-server:1.0.0
        ports:
        - name: http
          value: 8080
        env:
        - name: CACHE_SECRET
          value: cache
  parameters:
  - name: instanceName
    required: true
    fieldPaths:
    - ".metadata.name"
  - name: cacheSecret
    required: true
    fieldPaths:
    - ".workload.spec.containers[0].env[0].value"

fieldPaths es una matriz, cada elemento define los parámetros y la correspondiente carga de trabajo en el campo.

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: my-app-deployment
spec:
  components:
    - componentName: example-server
      parameterValues:
        - name: cacheSecret
          value: new-cache

En AppConfig en parameterValues ​​o ir a cubrir Componente del parámetro.

El principal nombre cambia a Componente 4 ComponentSchematic

componentes originales de este concepto llamado ComponentSchematic, la principal razón de este nombre se mezcla en el interior de algunos de la sintaxis y las opciones de descripción, como por la carga de trabajo Core ( container) y para la extensión de carga de trabajo ( workloadSettings), no es la misma que la redacción container de la definición de parámetros específicos, workloadSettings como es el esquema (explicar cómo llenar los parámetros). v1alpha1 versión de WorkloadSetting también integrado en el tipo / descripción de la clase, aún más ambigua.

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: rediscluster
spec:
  containers:
     ...
  workloadSettings:
    - name: engineVersion
      type: string
      description: engine version
      fromParam: engineVersion
     ...

En la versión v1alpha2, los componentes de este concepto cambió de componentes, claro como un ejemplo de la carga de trabajo, todas las definiciones de sintaxis se hace referencia en WorkloadDefinition CRD realidad definida.

En aplicación K8S, WorkloadDefinition es una referencia al CRD, Component.spec.workload está escrito en la instancia correspondiente CRD CR.

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: example-server
spec:
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: Server
    spec:
   ...

5 Ámbito grandes cambios creados solamente por CR, ya no creados por AppConfig

se crea Ámbito de v1alpha1 AppConfig, se puede ver del ejemplo, también es esencialmente un CR puede ser "derivado" para crear CR. Sin embargo, debido a la colocación de la Alcance puede acomodar diferente AppConfig en el Componente, y alcance en sí mismo no es una aplicación, a fin de utilizar AppConfig Crear ámbito sido inadecuado.

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: my-vpc-network
spec:
  variables:
    - name: networkName
      value: "my-vpc"
  scopes:
    - name: network
      type: core.oam.dev/v1alpha1.Network
      properties:
        network-id: "[fromVariable(networkName)]"
        subnet-ids: "my-subnet1, my-subnet2"

v1alpha2 uso completo de la nueva versión de la CR a la instancia correspondiente, con el fin de hacer que el concepto Alcance de la más clara y más conveniente para corresponder a diferentes tipos de Alcance, el alcance a cabo directamente definido por el correspondiente ScopeDefinition CRD CR creado. Ejemplos son los siguientes:

apiVersion: core.oam.dev/v1alpha2
kind: ScopeDefinition
metadata:
  name: networkscope.core.oam.dev
spec:
  allowComponentOverlap: true
  definitionRef:
    name: networkscope.core.oam.dev

apiVersion: core.oam.dev/v1alpha2
kind: NetworkScope
metadata:
  name: example-vpc-network
  labels:
    region: us-west
    environment: production
spec:
  networkId: cool-vpc-network
  subnetIds:
  - cool-subnetwork
  - cooler-subnetwork
  - coolest-subnetwork
  internetGatewayType: nat

Se utiliza en el ámbito AppConfig referencia de la siguiente manera:

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: custom-single-app
  annotations:
    version: v1.0.0
    description: "Customized version of single-app"
spec:
  components:
    - componentName: frontend
      scopes:
        - scopeRef:
            apiVersion: core.oam.dev/v1alpha2
            kind: NetworkScope
            name: my-vpc-network
    - componentName: backend
      scopes:
        - scopeRef:
            apiVersion: core.oam.dev/v1alpha2
            kind: NetworkScope
            name: my-vpc-network

Lista de variables 6 Cambios elimina principalmente y función dinámica [fromVariable ()]

Hay versión v1alpha1 variable de referencia de código abierto AppConfig en algunas variables públicas a reducir la redundancia, se unió a la lista de variables. Pero el punto de vista práctico, lo que reduce significativamente el redundante y no reducir la complejidad de especificación OAM, por el contrario, para aumentar la función dinámica aumenta significativamente la complejidad.

Por otro lado, fromVariable por esa capacidad de una plantilla puede timón / kustomiz hacer otras herramientas, estas herramientas hacen a una especificación OAM completa, entonces se utiliza.

Así que aquí una lista de variables y fromVariable asociada se eliminan, que no afecta a ninguna funcionalidad.

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: my-app-deployment
spec:
  variables:
    - name: VAR_NAME
      value: SUPPLIED_VALUE
  components:
    - componentName: my-web-app-component
      instanceName: my-app-frontent
      parameterValues:
        - name: ANOTHER_PARAMETER
          value: "[fromVariable(VAR_NAME)]"
      traits:
        - name: ingress
          properties:
            DATA: "[fromVariable(VAR_NAME)]"

Los principales cambios a 7 para reemplazar la carga de trabajo original de seis núcleos con ContainerizedWorkload

En la actualidad se define de manera uniforme por WorkloadDefinition carga de trabajo, Componente convertirse en un ejemplo de, por lo que los seis originales núcleo de carga de trabajo en realidad se convirtió en el mismo WorkloadDefinition, descripción del campo exactamente lo mismo, la única diferencia es un rasgo no son las mismas limitaciones y exigencias. Por lo tanto, el original de carga de trabajo de seis núcleo de spec, unificado tipo de modificación de carga de trabajo se llama ContainerizedWorkload de.

Mientras tanto, aquí se prevé aumentar por conceptos tales como la política, la investigación y el desarrollo para hacer expresar sus demandas para las estrategias de operación y mantenimiento que se pueden expresar la esperanza de componentes aumenta la cual rasgo.

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: containerizedworkloads.core.oam.dev
spec:
  definitionRef:
    name: containerizedworkloads.core.oam.dev

Uso ContainerizedWorkload una muestra:

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: frontend
  annotations:
    version: v1.0.0
    description: "A simple webserver"
spec:
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: ContainerizedWorkload
    metadata:
      name: sample-workload
    spec:
      osType: linux
      containers:
      - name: web
        image: example/charybdis-single:latest@@sha256:verytrustworthyhash
        resources:
          cpu:
            required: 1.0
          memory:
            required: 100MB
        env:
        - name: MESSAGE
          value: default
  parameters:
  - name: message
    description: The message to display in the web app.  
    required: true
    type: string
    fieldPaths:
    - ".spec.containers[0].env[0].value"

Los próximos pasos

  1. Entre los componentes de nivel de aplicación y dependencias de paso de parámetros ( flujo de trabajo );
  2. los programas de política , para facilitar la investigación y el desarrollo ponen demandas hacia adelante para rasgo en componentes;
  3. Componente aumento concepto de versiones, mientras que da una dirección de la MAO versión de la aplicación de forma relevante .

Preguntas comunes

  1. La transformación de nuestro modelo de OAM plataforma original para lograr lo que hay que hacer?

Para la gestión de aplicación de la plataforma estaba originalmente en K8S, la transformación de acceso de las implementaciones OAM se puede dividir en dos etapas:

  • Implementar OAM Controller ApplicationConfiguration (Controller AppConfig abreviado), que contiene el componente controlador de OAM, WorkloadDefinition, TraitDefinition, ScopeDefinition como CRD. El OAM AppConfig Controller AppConfig como se describe en, tirón CRD operador plataforma original;
  • Poco a poco el original CRD Operador de acuerdo con la idea de la separación de intereses, dividido en la carga de trabajo y el rasgo. Al mismo tiempo el acceso de la comunidad y OAM reutilización más carga de trabajo, Rasgo, rica en más escenas.

  1. CRD operador para acceder OAM existente lo que hay que hacer a cambio?

Existente CRD operador ** funciones OAM sistema sin problemas de acceso, tal como una extensión de carga de trabajo acceso independiente. Sin embargo, con el fin de permitir una mejor a los usuarios finales a darse cuenta de los beneficios de la separación de las preocupaciones OAM, se recomienda encarecidamente CRD mando En función de I + D y preocupaciones operacionales separamos en diferentes CRD, atención de la investigación CRD como la carga de trabajo OAM de acceso, problemas operacionales CRD es un rasgo acceso OAM.

Actualmente, las especificaciones de OAM y el modelo de realidad resuelven muchos de los problemas existentes, pero su viaje acaba de comenzar. OAM es un proyecto de código abierto neutro, damos la bienvenida a más personas a participar, definir conjuntamente el futuro de la distribución de aplicaciones de nube natal.

involucrados:

  • Código de uñas de escaneo para entrar en los grupos de discusión del proyecto OAM chinos

1.png

Sobre el autor

Sun Jianbo (apodo: Tianyuan) experto en tecnología de la nube Ali, es uno de los principales fabricantes de especificaciones OAM, comprometidos con la promoción de la estandarización de las aplicaciones en la nube natal. Mientras que también participa en la nube de Alibaba entrega de aplicaciones nativas y aplicaciones de gestión a gran escala de los trabajos relacionados. invita equipo de gestión de aplicaciones, Serverless experto, PaaS de campo para unirse, por favor contacto jianbo.sjb EN alibaba-inc.com

Reclutar personas que!

Nativo nube de plataforma de aplicaciones invita Kubernetes / sin servidor / PaaS / especialistas de entrega de aplicaciones (P6-P8) se unan a:

  • Experiencia laboral: recomendaciones de P6-7 tres años, cinco años a partir de P8, específicamente para ver la capacidad real;
  • Ubicación: China (Beijing / Hangzhou / Shenzhen); ultramar (San Francisco Bay Area / Seattle);
  • Mensajes incluyen: arquitectos, ingenieros y tecnólogos, otra pila completa.

Reanudar inmediatamente responder, de 2 a 3 semanas, los resultados, entrega curriculum vitae: jianbo.sjb AT alibaba-inc.com.

3 grupos viven .png cartel

" Alibaba nube nativa preocupación servicio de micro, sin servidor, contenedor, Servicio de malla y otros campos técnicos, centrándose tendencias tecnológicas populares nativas nube, nube de la práctica de aterrizaje a gran escala nativa, la mayoría lo hace entender círculos de tecnología de nube nativos de los desarrolladores."

Supongo que te gusta

Origin www.cnblogs.com/alisystemsoftware/p/12611500.html
Recomendado
Clasificación
Diario
Más
2024-06-08(0)
2024-06-07(0)
2024-06-06(0)
2024-06-05(0)
2024-06-04(0)
2024-06-03(1)
2024-06-02(0)
2024-06-01(2)
2024-05-31(0)
2024-05-30(0)

Code World

© 2018 codetd.com