Planning Your Kubernetes Cluster for Hybrid Manager Installation v1.2

Suggest edits

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.

← Prev

Kubernetes planning and minimum recommended requirements

↑ Up