Slice Management Issues

Onboarded Application Namespace Issues

Connectivity Issues with Multiple NSM Interfaces in ApplicationPods

Introduction

This scenario provides guidance on troubleshooting connectivity issues that arise when an application pod contains multiple NSM (Network Service Mesh) interfaces. The presence of older NSM interfaces in the router can lead to connectivity disruptions among the application pods. The following section outlines the resolution steps to reboot the application pod with multiple NSM interfaces, which will help restore the connectivity among the application pods.

Root Cause

Connectivity issues with NSM interfaces in application pods occur due to the presence of older NSM interfaces in the router. These older interfaces may conflict with the newer ones, leading to disruptions in communication among the application pods.

Impact

The impact of connectivity issues with multiple NSM interfaces includes: Communication Disruptions

Application pods may experience connectivity disruptions, resulting in failures to access essential network services and potential service unavailability.

Solution

To troubleshoot and resolve the connectivity issues with multiple NSM interfaces in application pods, follow these steps:

1. Identify Application Pods with Multiple NSM Interfaces

   Use the following command to identify the application pods that have multiple NSM interfaces:

   kubectl get pods -n <namespace> --selector=<label-selector> -o wide

   Example:

   kubectl get pods -n my-app-namespace --selector=app=my-app -o wide

   In the command output, observe the number of NSM interfaces present in each application pod.

2. Reboot Application Pods with Multiple NSM Interfaces

   For application pods that contain multiple NSM interfaces and are facing connectivity issues, reboot the pods to resolve the conflicts.

   Use the following command to delete and restart the application pod:

   kubectl delete pod <pod-name> -n <namespace>

   Example:

   kubectl delete pod my-app-pod-1 -n my-app-namespace

   Deleting the pod will trigger its automatic recreation with fresh NSM interfaces.

3. Verify Connectivity Restoration

   After the application pod is rebooted and recreated, verify if the connectivity among the application pods has been restored. Use appropriate tools or tests to validate that the application pods can now communicate seamlessly without any disruptions.

Conclusion

By following the provided steps, administrators can troubleshoot and resolve the connectivity issues associated with multiple NSM interfaces in application pods. Rebooting the application pods with multiple NSM interfaces will eliminate any conflicts between older and newer interfaces, allowing the application pods to communicate effectively and preventing potential connectivity disruptions.

Missing NSM Containers Injection in Application Namespace

Introduction

This scenario provides guidance on troubleshooting the issue when NSM (Network Service Mesh) containers are not injected into pods during deployments in the application namespace. NSM containers play a crucial role in managing network services for pods, and their absence can lead to communication failures and service disruptions. The solution below outlines steps to check if the application namespace contains the required KubeSlice label and provides instructions on waiting for the Slice Operator to label the namespace if necessary.

Root Cause

NSM containers may not be injected into pods during deployments in the application namespace due to a missing KubeSlice label on the namespace.

Impact

The impact of missing NSM containers includes:

**Network Service Disruptions **

Without NSM containers, pods may not have access to essential network services, resulting in communication failures and service unavailability.

Solution

To troubleshoot and resolve the issue of missing NSM containers in the application namespace:

1. Check for KubeSlice Label in Application Namespace

   Use the following command to check if the application namespace contains the KubeSlice label:

   kubectl describe ns <application-namespace>

   Example:

   kubectl describe ns iperf

   Expected Output:

   Name: iperf 
   Labels: hnc.x-k8s.io/included-namespace=true 
           iperf.tree.hnc.x-k8s.io/depth=0 
           kubernetes.io/metadata.name=iperf 
           kubeslice.io/slice=blue 
   Annotations: <none> 
   Status: Active 
   No resource quota. 
   No LimitRange resource.

   Check if the output contains the kubeslice.io/slice label. If the label is present, the namespace is onboarded to the specified slice.

2. Wait for the Slice Operator to Label the Namespace

   • If the kubeslice.io/slice label is missing in the application namespace, it indicates that the namespace is not yet onboarded to the desired slice.
   • In such cases, wait for the Slice Operator to label the namespace automatically. The Slice Operator is responsible for managing the labeling of namespaces and ensuring the correct injection of NSM containers.
   • Allow some time for the Slice Operator to process the namespace and apply the required labels. The process may take a few minutes to complete.
   • After the Slice Operator labels the namespace, verify if NSM containers are successfully injected into pods during deployments.

Conclusion

By following the provided steps, administrators can troubleshoot and resolve the issue of missing NSM containers injection in the application namespace. Ensuring the presence of NSM containers is vital for enabling proper network service management for pods within the namespace. If the KubeSlice label is missing, waiting for the Slice Operator to label the namespace will ensure the correct injection of NSM containers and prevent potential network service disruptions for deployed applications.

Resource Quota Issues

Pods Not Spinning Up in a Quota-Enforced Namespace

Introduction

This scenario provides guidance on troubleshooting the issue where pods are not spinning up in a namespace that has quota enforcement and limits configured. The issue might arise due to the pods exceeding the specified resource limits. The solution below outlines the steps to confirm and resolve this problem by adjusting the quota settings.

Root Cause

The root cause of pods not spinning up is likely that the pods have exceeded the resource limits specified in the quota configuration for the namespace. Kubernetes enforces quotas to limit the resources consumed by pods within a namespace.

Impact

The impact of pods not spinning up can lead to service unavailability or delayed deployment of applications within the namespace, affecting the overall performance and user experience.

Solution

To troubleshoot and resolve the issue of pods not spinning up in a quota-enforced namespace:

1. Confirm Exceeded Quota

   Use the following command to describe the replica set (RS) of the deployment:

   kubectl describe rs <rs-name>

   In the replica set description, check for the warning message that states the pods have exceeded the quota limits. The warning message will indicate the resource(s) for which the limits have been exceeded, as shown in the example provided.

2. Increase Quota Limit

   1. If the pods have exceeded the quota limits, increase the limit value of the pod count under the slice quota settings. This will allow more resources to be allocated for the pods within the namespace.
   2. Update the SliceResourceQuota configuration in the YAML file for the namespace to adjust the quota limits.Increase the value for limits.memory or other relevant resources to accommodate the requirements of the pods.

3. Delete Replica Set

   Use the following command to delete the replica set associated with the deployment:

   kubectl delete rs <rs-name>

   Deleting the replica set will trigger the recreation of the pods, and they will be created based on the updated quota settings.

4. Verify Pod Spin-up

   Check the pods in the namespace to confirm that they have spun up successfully.

   kubectl get pods -n <namespace>

   Observe the status of the pods to ensure that they are running without any issues.

Conclusion:

By following the provided steps, administrators can troubleshoot and resolve the issue of pods not spinning up in a namespace with quota enforcement and limits configured. By adjusting the quota settings and deleting the replica set,the pods will be recreated with the updated quota limits, allowing them to spin up successfully in the namespace.