The Configuration section helps you manage application settings, secrets, and resource organization in your Kubernetes cluster.
Overview
Kubernetes configuration resources organize and configure your workloads:
- ConfigMaps - Non-sensitive configuration data
- Secrets - Sensitive data like passwords and tokens
- Namespaces - Virtual clusters for resource isolation
- Limit Ranges - Default resource limits per namespace
- Pod Disruption Budgets - Protect workload availability
Accessing Configuration Resources
Navigate to your cluster and click Kubernetes in the sidebar. Configuration resources include:
| Resource | Path |
|---|
| ConfigMaps | Kubernetes → ConfigMaps |
| Secrets | Kubernetes → Secrets |
| Namespaces | Kubernetes → Namespaces |
| Limit Ranges | Kubernetes → Limit Ranges |
| Pod Disruption Budgets | Kubernetes → Pod Disruption Budgets |
ConfigMaps
ConfigMaps store non-sensitive configuration data as key-value pairs.
Viewing ConfigMaps
| Column | Description |
|---|
| Name | ConfigMap name |
| Namespace | Kubernetes namespace |
| Data | Number of data keys |
| Age | Time since creation |
ConfigMap Details
Click a ConfigMap to view:
- Data - Key-value pairs (displayed as editable text)
- Binary Data - Binary data keys (if any)
- Used By - Pods that mount or reference this ConfigMap
Using ConfigMaps
ConfigMaps can be used in pods as:
-
Environment Variables:
envFrom:
- configMapRef:
name: app-config
-
Volume Mounts:
volumes:
- name: config
configMap:
name: app-config
-
Individual Keys:
env:
- name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: app-config
key: log_level
Secrets
Secrets store sensitive data like passwords, tokens, and certificates.
Viewing Secrets
| Column | Description |
|---|
| Name | Secret name |
| Namespace | Kubernetes namespace |
| Type | Secret type (Opaque, TLS, etc.) |
| Data | Number of data keys |
| Age | Time since creation |
Secret Types
| Type | Description |
|---|
| Opaque | Generic user-defined secrets |
| kubernetes.io/tls | TLS certificates |
| kubernetes.io/dockerconfigjson | Docker registry credentials |
| kubernetes.io/service-account-token | Service account tokens |
| kubernetes.io/basic-auth | Username/password |
Secret Details
Click a Secret to view:
- Type - Secret type
- Data Keys - List of keys (values are hidden by default)
- Used By - Pods that mount or reference this Secret
Secret values are base64 encoded in Kubernetes but are shown decoded in the UI. Be careful when viewing in shared environments.
Security Best Practices
- RBAC: Limit who can read Secrets
- Encryption: Enable etcd encryption at rest
- Rotation: Regularly rotate sensitive credentials
- Minimal Scope: Only grant Secret access where needed
Namespaces
Namespaces provide virtual clusters within a physical cluster.
Viewing Namespaces
| Column | Description |
|---|
| Name | Namespace name |
| Status | Active or Terminating |
| Age | Time since creation |
Namespace Details
Click a Namespace to view:
- Status - Current phase
- Labels - Metadata labels
- Annotations - Additional metadata
- Resource Quotas - Applied quotas
- Limit Ranges - Default limits
System Namespaces
| Namespace | Purpose |
|---|
default | Default namespace for resources |
kube-system | Kubernetes system components |
kube-public | Publicly readable resources |
kube-node-lease | Node heartbeat leases |
Filtering by Namespace
Most resource views in Ankra allow filtering by namespace. Use the namespace selector at the top of resource lists to focus on specific namespaces.
Limit Ranges
Limit Ranges set default and maximum resource limits per namespace.
Viewing Limit Ranges
| Column | Description |
|---|
| Name | LimitRange name |
| Namespace | Applied namespace |
| Type | Container, Pod, PVC |
| Age | Time since creation |
Limit Range Details
- Default Limits - Applied if not specified
- Default Requests - Default resource requests
- Max - Maximum allowed resources
- Min - Minimum required resources
- Max Limit/Request Ratio - Limit/request ratio cap
Example
limits:
- type: Container
default:
cpu: 500m
memory: 256Mi
defaultRequest:
cpu: 100m
memory: 128Mi
max:
cpu: 2
memory: 1Gi
Pod Disruption Budgets
PDBs protect application availability during voluntary disruptions.
Viewing PDBs
| Column | Description |
|---|
| Name | PDB name |
| Namespace | Kubernetes namespace |
| Min Available | Minimum pods required |
| Max Unavailable | Maximum pods that can be down |
| Allowed Disruptions | Current allowed disruptions |
PDB Details
- Selector - Which pods this PDB protects
- Min Available / Max Unavailable - Availability constraint
- Current Healthy - Pods currently healthy
- Desired Healthy - Target healthy count
- Disruptions Allowed - How many can be disrupted now
Use Cases
- Rolling Updates: Ensure minimum replicas during updates
- Node Maintenance: Protect workloads during node drains
- Cluster Autoscaler: Prevent over-aggressive scale-down
Common Tasks
Creating a ConfigMap
While Ankra focuses on visibility, you can create ConfigMaps through:
- Stacks - Add a manifest with your ConfigMap definition
- kubectl - Apply YAML directly to the cluster
- GitOps - Sync from your Git repository
Viewing Secret Values
- Navigate to Secrets
- Click on the Secret
- Click Reveal next to a key to show the decoded value
Troubleshooting Namespace Termination
If a namespace is stuck in Terminating:
- Check for finalizers blocking deletion
- Look for resources that can’t be deleted
- View events for error messages
- Check for webhook failures
Tips
Namespace Isolation: Use namespaces to separate environments (dev, staging, prod) or teams.
ConfigMap Updates: Changes to ConfigMaps require pod restart unless using volume mounts with automatic refresh.
Secret Management: Consider external secret management (Vault, AWS Secrets Manager) for production secrets.
Still have questions? Join our Slack community and we’ll help out.
