Network engineering continued ...

 Network engineering continued ...

This is a continuation of the earlier posts starting with this one: http://ravinote.blogspot.com/2020/09/best-practice-from-networking.html

663. 665. The containerized image built must be registered in the hub so that it is made available everywhere. 

     666. 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.

     667. 
          

664. 
     

665. 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.

666. 
     

667. The parameters for the task are best described in the declarative syntax associated with the so-called custom resource required for these deployment operators 

668. 
     

664. 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 

665. 
     

665. 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.

668. 
     

669. 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.