Cluster computing

Wednesday, December 23, 2020

Operators like update involve scaling down the nodes, then performing the update, and then scaling back up. There is no restriction to reuse logic between operators.

Operators generally work one at a time on the same cluster. This prevents states from being mixed and allowing each reconcile between state and deploys to happen sequentially.

Operators do not have to retain any information between invocations. Anything that needs to be persisted must be part of the state.

There is no limit to the number of operators run during deployment. It is preferred to run them sequentially one after the other. The more granular the operators the better they are for maintenance.

The diagnosability of operators improves with each operator being small and transparent.

The upgrade operator can be rolling upgrades. Then the operator does not require scale up or down.

The operators can invoke methods defined in other operators if they are accessible.
2. There is a lot in common between installer packages on any other desktop platform and the containerization deployment operators.
1. The setup of access and access control are part of the operator actions for deployment and they remain some of the core requirements for the deployment of the product.
2. Networking products keep a journal with the data which helps with packet processing.
  Networking products also keep a state machine for the protocol pertaining to the packets.
  Networking products allow testing of the packet content, format, sequence, and driver state machine transitions.

1. The containerized image built must be registered in the hub so that it is made available everywhere.
1. There are many features on the container orchestration framework that the networking product can leverage to free itself from the concerns of the infrastructure. Some of these features are available via the SDK. Container technologies also evolve to keep pace with the Infrastructure as a service and cloud technologies.
The type of features from the operator SDK used by a networking product depends on the automation within the container-specific operator specified by this product. If the product wants to take on more of the infrastructure routine from the container orchestration framework, it can certainly do so otherwise the operator and the framework enable it to do just the minimum.
The parameters for the task are best described in the declarative syntax associated with the so-called custom resource required for these deployment operators

The number of tasks or their type depends on the application and can become sophisticated and customized. There is no restriction to this kind of automation

One of these features is metering and it works the same way as in the public cloud. The container orchestration framework allows this to be extended so that the product can write its own metric operator.

The operators can be written in a variety of languages depending on the SDK, but a barebone application without heavy interpreters or compilers is preferred. Go language is used for these purposes and particularly in DevOps.