This design and relaxation of performance requirements from applications hosted on Kubernetes facilitates different connectors not just volume mounts. Just like we have log appenders publish logs to a variety of destinations, connectors help persist data written from the application to a variety of storage providers using consolidators, queues, cache and mechanisms that know how and when to write the data.
Unfortunately, the native Kubernetes API does not support any other forms of storage connectors other than the VolumeMount but it does allow services to be written in the form of Kubernetes applications that can accept the data published over http(s) just like a time series database server accepts all kinds of events over the net. The configuration of the endpoint, the binding of the service and the contract associated with the service vary from app to app. This may call for a well-known consolidator app that can provide different storage class that support different application profiles. Appenders and connectors are popular design patterns that get re-used often and justify their business value.
The shared data volume can bee made read-only and accessible only to the pods. This facilitates access restrictions. While authentication, authorization and audit can be enabled for storage connectors, they will still require RBAC access. Therefore, service accounted become necessary with storage connectors. A side-benefit of this security is that the accesses can now be monitored and alerted.
Storage is a layer best left outside the application logic. The applications continue to streamline their business while the storage provides best practice. When the storage layer is managed, it’s appeal grows. For applications that use the container framework, the storage is generally network accessible . There tasks such as storage virtualization, replication and maintenance can be converged into a layer external from the application and reachable over the network.
Storage is not the only layer. The container framework benefits from its own platform as a service. Plugins that perform routines such as monitoring, healing, auditing, can all be delegated to plugins that can be shipped out of the box from the container framework. Then these bundles can be different sized.
Kubernetes itself is very helpful for applications of all sizes. These plugins are merely add-ons.
Unfortunately, the native Kubernetes API does not support any other forms of storage connectors other than the VolumeMount but it does allow services to be written in the form of Kubernetes applications that can accept the data published over http(s) just like a time series database server accepts all kinds of events over the net. The configuration of the endpoint, the binding of the service and the contract associated with the service vary from app to app. This may call for a well-known consolidator app that can provide different storage class that support different application profiles. Appenders and connectors are popular design patterns that get re-used often and justify their business value.
The shared data volume can bee made read-only and accessible only to the pods. This facilitates access restrictions. While authentication, authorization and audit can be enabled for storage connectors, they will still require RBAC access. Therefore, service accounted become necessary with storage connectors. A side-benefit of this security is that the accesses can now be monitored and alerted.
Storage is a layer best left outside the application logic. The applications continue to streamline their business while the storage provides best practice. When the storage layer is managed, it’s appeal grows. For applications that use the container framework, the storage is generally network accessible . There tasks such as storage virtualization, replication and maintenance can be converged into a layer external from the application and reachable over the network.
Storage is not the only layer. The container framework benefits from its own platform as a service. Plugins that perform routines such as monitoring, healing, auditing, can all be delegated to plugins that can be shipped out of the box from the container framework. Then these bundles can be different sized.
Kubernetes itself is very helpful for applications of all sizes. These plugins are merely add-ons.
No comments:
Post a Comment