feat: add troubleshooting category in Spanish and remove FAQItem comp…

docs/network.mdx

@@ -0,0 +1,70 @@
+---
+id: network-resources
+title: Network Resources
+sidebar_label: Network Resources
+sidebar_position: 9
+---
+import Zoom from "react-medium-image-zoom";
+
+# Network Resources
+
+This documentation provides a clear and simple overview of the network architecture that SleakOps deploys in client environments. It explains how the network is organized, how resources are protected, and how both internal and external communication is managed.
+
+> ❓ **Note:** The network is designed to ensure security, scalability, and high availability. It enables environment separation, protects sensitive data, and exposes services in a secure and controlled way.
+
+## 1. Overview of the Architecture
+
+The SleakOps network infrastructure is based on the following key components:
+
+- **VPC (Virtual Private Cloud):** Segregates networks by environment (Management, Production, Development).
+- **Subnets:**
+  - *Public:* exposed to the Internet.
+  - *Private:* restricted access, Internet access via NAT Gateway.
+  - *Persistence:* for databases and storage.
+- **Internet Gateway:** Enables communication between the VPC and the Internet.
+- **Route Tables:** Define routing paths between subnets and to/from the Internet.
+- **Security Groups:** Virtual firewalls that control inbound and outbound traffic for resources.
+- **Internal DNS:** Allows internal resources to communicate using hostnames instead of IP addresses.
+- **External-DNS:** Runs inside each Kubernetes (EKS) cluster and automatically manages public DNS records in Route53 for exposed services.
+
+## 2. Typical Communication Flow
+
+The following illustrates a typical flow of network traffic in SleakOps:
+
+1. **Access from the Internet:**  
+   A user accesses a publicly exposed service (e.g., an API). Traffic reaches the Internet Gateway and is routed to the public subnet.
+
+2. **Access Control:**  
+   The Security Group associated with the resource evaluates whether the connection is allowed.
+
+3. **Internal Communication:**  
+   Internal services (in private or persistence subnets) communicate using internal DNS, under Security Group rules.
+
+4. **Service Exposure:**  
+   If a service within a Kubernetes cluster needs to be publicly accessible (e.g., an API), it is exposed via an Application Load Balancer, and External-DNS registers the public domain automatically in Route53.
+
+> This segmentation and control ensure that only necessary services are exposed while keeping sensitive data protected.
+
+<Zoom overlayBgColorEnd="rgba(255, 255, 255, 0.8)">
+  <img
+    src="/img/network/sleakops-network.png"
+    alt="reference-architecture"
+  />
+</Zoom>
+
+## 3. External-DNS and Route53
+
+An automated solution is used to manage public DNS records for deployed services, integrating the infrastructure with external DNS providers like Route53.
+
+- External-DNS **does not expose services directly**. It automates DNS record management for resources that are already exposed (e.g., via an Application Load Balancer).
+- This allows services to be securely and easily accessible from the Internet.
+
+## 4. Cross-Environment Connectivity via VPC Peering
+
+To enable controlled communication between environments (e.g., between Management and Production), SleakOps sets up **VPC Peering connections** between the different VPCs.
+
+- **VPC Peering** enables two VPCs to exchange internal traffic as if they were part of the same network.
+- **It does not require** Internet, NAT Gateway, or VPN traffic routing.
+- It is a direct connection between two networks.
+
+> 💡 Besides Internet Gateway access, SleakOps also supports other connectivity options such as **Pritunl VPN**, **NAT Gateway**, and **Transit Gateway**, depending on use case and required isolation level.

docs/troubleshooting/_category_.json

@@ -0,0 +1,11 @@
+{
+  "label": "Troubleshooting", 
+  "position": 8,
+  "collapsible": true,
+  "collapsed": true,
+  "description": "Common issues and solutions for SleakOps users",
+  "link": {
+    "type": "doc",
+    "id": "troubleshooting/index"
+  }
+}

docs/troubleshooting/api-access-troubleshooting-private-services.mdx

@@ -0,0 +1,254 @@
+---
+sidebar_position: 3
+title: "Private API Service Access Issues"
+description: "Troubleshooting connectivity issues with private API services in Kubernetes clusters"
+date: "2024-12-19"
+category: "user"
+tags: ["api", "vpn", "private-service", "connectivity", "troubleshooting"]
+---
+
+import TroubleshootingItem from "@site/src/components/HomepageFeatures/troubleshootingitem";
+
+# Private API Service Access Issues
+
+**Date:** December 19, 2024  
+**Category:** User  
+**Tags:** API, VPN, Private Service, Connectivity, Troubleshooting
+
+## Problem Description
+
+**Context:** Users experiencing connectivity issues when trying to access private API services deployed in Kubernetes clusters through SleakOps platform.
+
+**Observed Symptoms:**
+
+- Unable to connect to private API services
+- API requests timing out or failing
+- Intermittent connectivity issues
+- Services accessible internally but not externally
+
+**Relevant Configuration:**
+
+- Service type: Private API service
+- Network: Kubernetes cluster with private networking
+- Access method: VPN connection required
+- Service exposure: Internal cluster networking
+
+**Error Conditions:**
+
+- Connection failures when VPN is not active
+- API unreachable from external networks
+- No response from private service endpoints
+- Network timeout errors
+
+## Detailed Solution
+
+<TroubleshootingItem id="vpn-connection-check" summary="Verify VPN Connection Status">
+
+First, ensure your VPN connection is active and properly configured:
+
+1. **Check VPN Status:**
+
+   - Verify VPN client is connected
+   - Check connection status in your VPN client
+   - Ensure you're connected to the correct VPN profile
+
+2. **Test VPN Connectivity:**
+
+   ```bash
+   # Test connectivity to cluster internal networks
+   ping <cluster-internal-ip>
+
+   # Check if you can reach cluster DNS
+   nslookup <service-name>.<namespace>.svc.cluster.local
+   ```
+
+3. **Verify Network Routes:**
+   ```bash
+   # Check routing table
+   route -n  # Linux/Mac
+   route print  # Windows
+   ```
+
+</TroubleshootingItem>
+
+<TroubleshootingItem id="service-accessibility" summary="Verify Service Configuration">
+
+Check if the API service is properly configured for private access:
+
+1. **Check Service Type:**
+
+   ```bash
+   kubectl get svc <service-name> -n <namespace>
+   ```
+
+2. **Verify Service Endpoints:**
+
+   ```bash
+   kubectl get endpoints <service-name> -n <namespace>
+   ```
+
+3. **Check Service Configuration:**
+   ```yaml
+   # Example private service configuration
+   apiVersion: v1
+   kind: Service
+   metadata:
+     name: private-api-service
+     namespace: default
+   spec:
+     type: ClusterIP # Internal access only
+     ports:
+       - port: 80
+         targetPort: 8080
+     selector:
+       app: api-service
+   ```
+
+</TroubleshootingItem>
+
+<TroubleshootingItem id="pod-logs-analysis" summary="Analyze Pod Logs for API Issues">
+
+Examine pod logs to identify potential issues:
+
+1. **Check API Pod Logs:**
+
+   ```bash
+   # Get pod logs
+   kubectl logs <pod-name> -n <namespace>
+
+   # Follow logs in real-time
+   kubectl logs -f <pod-name> -n <namespace>
+
+   # Get logs from all containers in pod
+   kubectl logs <pod-name> -n <namespace> --all-containers
+   ```
+
+2. **Look for Common Issues:**
+
+   - Connection timeouts
+   - Authentication failures
+   - Resource constraints
+   - Database connectivity issues
+
+3. **Check Pod Status:**
+   ```bash
+   kubectl get pods -n <namespace>
+   kubectl describe pod <pod-name> -n <namespace>
+   ```
+
+</TroubleshootingItem>
+
+<TroubleshootingItem id="network-troubleshooting" summary="Network Connectivity Troubleshooting">
+
+Perform network-level troubleshooting:
+
+1. **Test from Within Cluster:**
+
+   ```bash
+   # Create a debug pod
+   kubectl run debug-pod --image=nicolaka/netshoot -it --rm
+
+   # Test connectivity from inside cluster
+   curl http://<service-name>.<namespace>.svc.cluster.local
+   ```
+
+2. **Check Network Policies:**
+
+   ```bash
+   kubectl get networkpolicies -n <namespace>
+   ```
+
+3. **Verify DNS Resolution:**
+
+   ```bash
+   # From debug pod
+   nslookup <service-name>.<namespace>.svc.cluster.local
+   ```
+
+4. **Test Port Connectivity:**
+   ```bash
+   # Test specific port
+   telnet <service-ip> <port>
+   nc -zv <service-ip> <port>
+   ```
+
+</TroubleshootingItem>
+
+<TroubleshootingItem id="ingress-configuration" summary="Configure Ingress for External Access">
+
+If you need external access to the private API:
+
+1. **Create Ingress Resource:**
+
+   ```yaml
+   apiVersion: networking.k8s.io/v1
+   kind: Ingress
+   metadata:
+     name: private-api-ingress
+     namespace: default
+     annotations:
+       nginx.ingress.kubernetes.io/rewrite-target: /
+   spec:
+     rules:
+       - host: api.yourdomain.com
+         http:
+           paths:
+             - path: /
+               pathType: Prefix
+               backend:
+                 service:
+                   name: private-api-service
+                   port:
+                     number: 80
+   ```
+
+2. **Configure TLS (Optional):**
+   ```yaml
+   spec:
+     tls:
+       - hosts:
+           - api.yourdomain.com
+         secretName: api-tls-secret
+   ```
+
+</TroubleshootingItem>
+
+<TroubleshootingItem id="common-solutions" summary="Common Solutions and Best Practices">
+
+**Quick Fixes:**
+
+1. **Restart VPN Connection:**
+
+   - Disconnect and reconnect VPN
+   - Try different VPN servers if available
+
+2. **Clear DNS Cache:**
+
+   ```bash
+   # Linux
+   sudo systemctl flush-dns
+
+   # macOS
+   sudo dscacheutil -flushcache
+
+   # Windows
+   ipconfig /flushdns
+   ```
+
+3. **Check Firewall Rules:**
+   - Ensure local firewall allows VPN traffic
+   - Verify corporate firewall settings
+
+**Best Practices:**
+
+- Always connect to VPN before accessing private services
+- Use service discovery instead of hardcoded IPs
+- Implement proper health checks for API services
+- Monitor service logs regularly
+- Set up alerts for service availability
+
+</TroubleshootingItem>
+
+---
+
+_This FAQ was automatically generated on December 19, 2024 based on a real user query._