Kubernetes Secrets
Kubernetes is a system for managing the containerized applications. It facilitates deployment and scaling. As part of deployment, applications have to set up accounts, passwords and other secrets. These secrets are necessary to be made available as files and environment variables for the deployment to go through.
The infrastructure provides a standard way of keeping these secrets. The secret is specified declaratively and then subsequently made available to the application. It can also be specified dynamically by the application code.
The secret is kept in the form of base64 encoded data. The secret can be written out a file on mounted volume for use by the application. In such case, it is preferable to mark the volume as read only. The secret can be accessible from any pod in the system
Since there is no limit to the size of the size of data stored as secrets almost any file can be base64 encoded and passed as secret. However, large files are generally not preferable as secrets instead they could be password protected and the passwords could become secrets.
There is no limit to the number of secrets that can be passed to the pods. However, it is better to enumerate them so that they remain in one place for consistent treatment.
Common forms of secrets involve account names, passwords, groups, identifiers, keys, certificates,  keystores and truststores. These secrets can be at most a few thousand bytes in size.  However, the type of secret determines its handling. Passwords can be managed in an external vault.  Certificates, for example, can be managed by a certificate manager. Certificates can be from different issuers. ACME issuer supports certificates from its server. CA supports issuing certificates using a signing key pair. Vault supports issuing certificates using a common vault. Self-signed certificates are issued privately. Venafi certificates supports issuing certificate from a cloud or a platform instance.
Although Kubernets manages the secrets, a consolidator can help with specific secret types. The libraries for this such as cert-manager are quite popular and well documented.   The use of libraries also brings down the code in the application to manage these specific types of secrets. The external dependencies for generating secrets are similar to any other dependency for the application code so these can be registered and maintained in one registry.
All external dependencies involve some maintenance as they go through their own revisions. However, an application deployment that is tested with a fixed type of dependencies will not need to revise its dependencies.


Get the preorder successor of a node. A successor is one that comes after the node in the preorder traversal)
Node GetPreorderSuccessor(Node root, Node x)
{
Node result = null;
if (root == null || x == null || x == root) return result;
var list = new List<Node>();
ToPreOrder(ref list, root);
int index = root.indexOf(ref list, x);
if ( index >= 0 && index < list.Count()-1)
      return list[index+1];
return result;
}
static void ToPreOrder(ref List<Node> nodes, Node root)
{
if (root == null) return;
nodes.Add(root);
ToPreOrder(ref nodes, root.left);
ToPreOrder(ref nodes, root.right);
}