Editing registry settings by version

🌐 This document is available in both English and Ukrainian. Use the language toggle in the top right corner to switch between versions.

1. General description

In the current version of the Platform, the admin console version is a component of the Platform and registers management subsystem and is updated together with the Platform.

After the update, provided that there were changes in the work with registry settings in values.yaml may cause problems with managing those registries that, for one reason or another, have not yet been updated to of the latest version due to the incompatibility of the specification of the old values.yaml and the new logic of the admin console.

To solve this versioning problem, three options were considered:

Version control at the code base level of the admin console
Separation of the admin console into two separate consoles: platform and registry and update them independently
Routing between different versions of the admin console using Istio rules

In this transitional design, it was decided to consider a third option to solve these problems because of its relative ease of implementation

User roles

Technical registry administrator
Technical administrator of the Platform

2. Functional scenarios

Application of Istio routing rules for automatic network switching of traffic between versions of the admin console
Deployment of the new version of the admin console as a separate deployment with the specified version.

3. General provisions

Along with the Platform update, the admin consoles of previous versions should remain deployed
The root for all existing admin consoles remains the same
The admin console, when going to the page for viewing/editing a specific registry, must insert its version in query parameters
The admin console controller must check the correspondence of the version set in the request parameter and the version of the registry where the user goes
If there are no registries left on the cluster with the version for which the admin console is intended, then it must be deleted together with by routing rules when starting cluster-mgmt pipeline
To support the function of creating registries of old versions, the admin console of the previous version (N-1) must always remain on the cluster and versions of existing registers on the Platform
Routing logic between versions is transferred to the Istio layer
Tags on the registry creation page should display only the current version and one previous version, and all others should be hidden.

4. Technical solution design

The Istio VirtualService defines a set of traffic routing rules that are applied when contacting a host. Each routing rule defines eligibility criteria for traffic of a specific protocol. If the traffic matches, it is sent to the appropriate version of the admin console. In this case, the criterion of compliance will be HTTP Request parameter.

Figure 1. Top-level diagram

For example, consider two versions of the admin console 1.9.3 and 1.9.4.

Figure 2. Two versions of the admin console are deployed in the cluster

By default, there are no additional options, and the technical administrator is in this case uses the latest available version of the admin console to view the list of created registers, manage the Platform and creation of new registers.

Figure 3. Without parameters, traffic goes to the latest version by default

When you go to the page for viewing/editing a specific registry, the admin console takes its version and pastes it parameter version=1.9.3 in the request. Istio Envoy reads the version parameter and redirects traffic to on instances of the admin console of the corresponding version by selector.

Figure 4. With the parameter, the traffic goes to the specific specified version

To prevent the issue of version conflicts when a user forwards or bookmarks a link to the registry, the admin console controller must check the version set in the request parameter and the registry version where the user goes. If the versions do not match, show the page with the offer to return to the page from list of registers.

When deploying the admin console, the following changes should occur:

In the labels and deployment selectors of the admin console, the version of the Platform for which it is intended should be inserted. For example, consider version 1.9.4:
```
app: control-plane-console
version: 1.9.4
```
The `control-plane' namespace has the following annotations:
```
istio-injection: enabled
kiali-enabled: 'true'
```

Istio-ingressgateway must also be deployed in the `control-plane' namespace. Examples:

Gateway deployment

ingressGateways:
  - enabled: true
    k8s:
      hpaSpec:
        maxReplicas: 1
        minReplicas: 1
      service:
        type: ClusterIP
    label:
      istio: istio-ingressgateway-control-plane
    name: istio-ingressgateway-control-plane
    namespace: control-plane

Gateway description

kind: Gateway
apiVersion: networking.istio.io/v1alpha3
metadata:
  name: gateway
  namespace: control-plane
  labels:
    app.kubernetes.io/managed-by: Helm
spec:
  servers:
    - hosts:
        - control-plane-console.apps.<cluster-wildcard>
      port:
        name: http2
        number: 80
        protocol: HTTP
  selector:
    istio: istio-ingressgateway-control-plane

The admin console deployment has the istio sidecar inject label:
```
sidecar.istio.io/inject: 'true'
```

The route of the admin console points to the service `istio-ingressgateway'. Example:

spec:
  host: control-plane-console.apps.<cluster-wildcard>
  to:
    kind: Service
    name: istio-ingressgateway-control-plane
    weight: 100
  port:
    targetPort: http2

Configuring VirtualService and DestinationRule for routing depending on the request parameter. Example:

kind: DestinationRule
apiVersion: networking.istio.io/v1alpha3
metadata:
  name: control-plane
  namespace: control-plane
spec:
  host: control-plane-console.control-plane.svc.cluster.local
  subsets:
    - labels:
        app: control-plane-console
        version: 1.9.3
      name: v1-9-3
    - labels:
        app: control-plane-console
        version: 1.9.4
      name: v1-9-4

kind: VirtualService
apiVersion: networking.istio.io/v1alpha3
metadata:
  name: cp-console
  namespace: control-plane
spec:
  hosts:
    - control-plane-console.apps.<cluster-wildcard>
  gateways:
    - gateway
  http:
    - match:
        - uri:
            regex: /registry/[^/]+
          queryParams:
            version:
              exact: 1.9.3
      name: version-1.9.3
      route:
        - destination:
            host: control-plane-console.control-plane.svc.cluster.local
            port:
              number: 8080
            subset: v1-9-3
    - match:
        - uri:
            regex: /registry/[^/]+
          queryParams:
            version:
              exact: 1.9.4
      name: version-1.9.4
      route:
        - destination:
            host: control-plane-console.control-plane.svc.cluster.local
            port:
              number: 8080
            subset: v1-9-4
    - name: version-1.9.4
      route:
        - destination:
            host: control-plane-console.control-plane.svc.cluster.local
            port:
              number: 8080
            subset: v1-9-4

Registry components and their purpose within the solution design

Component

Official title

Appointment / The essence of the changes

The web interface is the interface for managing the Platform and registries

control-plane-console

Changes in the controller, adding headers

Deployment of the platform and registries

edp-library-stages-fork

Changing the deployment logic of Istio-ingressgateway

Service for inspection and storage of configuration changes

control-plane-gerrit

Change of cluster-mgmt templates to deploy istio configuration

Інсталлятор Платформи

control-plane-installer

Changing the packaging and versioning logic of admin consoles

5. Development plan

5.1. Technical examinations

FE
DevOps

5.2. Development plan

Extending the functionality of the admin console to manage registry version parameters, control the registry version and the version in the header, hiding past tags in the registry creation menu
Changing logic of packing, versioning and updating admin consoles in control-plane-installer
Development of Istio routing rules
Extension of deploy-via-helmfile stage with Istio-ingressgateway deployment functionality

6. Data migration when updating the registry

For Platform versions below 1.9.5, provide the ability to configure Istio routing rules for legacy clusters with one console