Currently, the edge cluster agent is installed with cluster permissions which must be granted by the Kubernetes cluster admin. This means that a DevOps team wishing to make use of Open Horizon is required to engage the Ops team responsible for providing Kubernetes services. In order to enable DevOps to be more self sufficient, this barrier needs to be removed. In effect, an edge cluster agent installed with permission to a specific namespace becomes responsible for managing application deployments in that namespace, and only in that namespace. An edge cluster agent installed like this is no longer able to install services into any namespace (as it does currently). As a result, OH will be responsible for preventing namespace specific edge agents from attempting to deploy services into a namespace other than the agent's namespace.
However, once this barrier is removed, another set of use cases surfaces. When multiple DevOps teams are utilizing an edge cluster in this way, they are effectively using it in a pseudo multi-tenant fashion. That is, each DevOps team would expect to be able to manage their own agents and services deployed by those agents without interference from agents in other namespaces within the same cluster. To the extent that Kubernetes administration enables multi-tenancy within a cluster, a namespace scoped agent supports those goals.
The use cases for a single cluster scoped agent with cluster wide permissions are still valid and are not altered by this design. In addition, it is desire-able that a single edge cluster contains both a cluster scoped agent and one or more namespace scoped agents.
It is not a goal of this design to provide an edge cluster agent that supports more than 1 namespace but less than the entire cluster.
Agent Install:
The agent install script is updated to include a namespace flag indicating the target namespace of the agent:
./agent_install.sh --namespace MyProjectNamespace ...
The user invoking the install script MUST have permission to the MyProjectNamespace, otherwise the install will fail. The absence of the --namespace flag indicates a desire to install an agent with cluster wide permissions.
Node Properties:
A new built-in node property called openhorizon.kubernetesNamespace is introduced, the value reflects the namespace in which the agent is installed. This property is read-only, it is always set by the OH runtime and is not settable by any user role. This property MAY be used in a deployment policy constraint expression.
Service Definition:
<TBD>
Deployment:
A new field is added to the service section of a deployment policy, indicating the target namespace for the service's deployment.
"service": { ...
"namespace": <string>
}This field is optional and ignored for services deployed to a device.
A cluster based service MAY contain a namespace definition (yaml), which indicates the namespace in which the service should be deployed. The yaml file is packaged with the operator definition in the cluster deployment section of the service definition. This is already supported in the agent.
A namespace specified in the deployment policy overrides any namespace defined in the operator definition.
The Agbot calculates the target namespace of a cluster based service as follows:
- If present, use the namespace in the deployment policy.
- If present, use the namespace in the service definition.
- Use openhorizon-agent namespace (this is the default namespace where the cluster scoped agent is installed).
Once the Agbot has calculated the target namespace it:
- Uses this namespace as a built-in constraint when searching for deployment targets.
Patterns:
A new field is added to the schema of a pattern, indicating the target namespace for the pattern's deployment.
"namespace": <string>
The namespace field is optional and ignored for patterns deployed to a device.
A namespace specified in the pattern overrides any namespace defined in the operator definition of all services in the pattern.
A pattern is in error if it attempts to deploy services to a namespace scoped node where the collection of services in the pattern are NOT deployable to the same namespace. Clearly this can only happen when the namespace is NOT specified in the pattern definition but is contained within the operator definition.
DevOps user - a conflation of roles found in the practice of DevOps; e.g. service developer, or service deployer.
As a DevOps user, I want to install the OH agent into one or more namespaces that I have permission to use for my project.
As a DevOps user, I want to select the namespace into which a service is deployed.
As a DevOps user, I want OH to ensure that other DevOps teams (in the same OH organization/tenant) are unable to deploy applications into my namespaces.
As a node owner, I want OH ensure that DevOps teams using my edge cluster are isolated from each other, based on the namespace(s) I have given to each team.