Planning Your Kubernetes Cluster for Hybrid Manager Installation

When preparing to deploy Hybrid Manager (HM), make certain to first consider the following preliminary aspects of the design:

1. Use Case

• What workloads need to be managed?

• Are you deploying in production, testing, or a hybrid environment?

2. Base Infrastructure

• Is the cluster to be hosted by a Cloud Service Provider (CSP) or on-premises?
  • For on-premises, consider bare-metal, VM, or private cloud options.

3. Networking

• Availability zones and subnets (public/private)

• NAT Gateway/Egress

• Network security rules

• Resource tagging and latency considerations

• Network security

  • Cluster network policies
    • Implement Kubernetes network policies to control traffic flow between pods, namespaces, and external resources.
  • Encrypted communication
    • Use TLS for all communication between HM components and external clients.
    • Ensure in-cluster service communication is encrypted
  • Firewalls and security groups
    • For on-premises deployments, configure firewalls to restrict access to Kubernetes API servers and control-plane nodes.
    • For cloud-based deployments, utilize security groups to restrict inbound and outbound traffic to the cluster

4. Kubernetes Cluster Settings

• Kubernetes version.

• Identity management (e.g., LDAP, SAML, OpenID Connect).

• Resource tags, secrets/config maps.

• Taints and tolerations for node groups.

5. Node Group Configuration

• Instance types and compute groupings.

6. Permission Policies

• PGAIHM needs permissions to the whole Kubernetes cluster

• Node role permissions and RBAC settings.

• Quotas and limit ranges.

• Network policies.

7. Storage Integration

• CSI drivers and object storage (e.g., S3-compatible).

• Volume types, persistent volume claims, and snapshot support.

8. Load Balancer/Ingress Integration

• Cloud provider or on-premises specifics.

• Permissions for load balancer integration.

9. Data security

- Encryption at rest
    - Ensure persistent volumes used by HM have encryption enabled
    - Use a storage backend that supports encryption (e.g. AWS S3 for backups in EKS, NVMe with encryption for local storage on-premises)
- Encryption in transit
    - Enable encryption for all data transfer between HM components and the database clusters they manage.
- Secrets management
    - Store all sensitive information (e.g. database passwords, API keys) in Kubernetes Secrets.
    - Use a secure external secrets manager (e.g. HashiCorp Vault, AWS Secrets Manager) when possible.

10. Platform-Specific Custom Configurations

• Differences between Red Hat OpenShift, AWS EKS, and other distributions.

By addressing these considerations, you can ensure your Kubernetes cluster is properly configured to support HM in any deployment scenario.