Welcome to Edera

Customer training for authorized users only

Only users with authorized email domains can access this portal.
Contact support@edera.dev if you need assistance.

Getting Support

You’ve tried the troubleshooting steps, checked the logs, and verified configurations. Sometimes you need expert help. Here’s how to get it.

When to Contact Support

Reach out when:

  • You’ve followed debugging workflows but the issue persists
  • You encounter errors you don’t understand
  • You need guidance on architecture or deployment decisions
  • You’re planning a production rollout and want validation
  • You discover potential bugs or unexpected behavior

Don’t hesitate. Edera support is always here to help. Think of Edera support as an extension of your team.

How to Contact Support

Email

Primary support channel:

Documentation

Self-service resources:

What to Include in Your Support Request

The more context you provide, the faster the team can help.

Essential Information

1. Environment details:

  • Kubernetes version: kubectl version --short
  • Node operating system: cat /etc/os-release
  • Cloud platform (AWS, Azure, on-prem, etc.)
  • Cluster size and node types

2. Edera version:

  • AMI ID (for AWS deployments)
  • Installer version (if using the Edera installer)
  • Check service versions: systemctl status protect-daemon | head -5

3. Problem description:

  • What you were trying to do
  • What happened instead
  • When the issue started
  • Whether it’s consistent or intermittent

4. Steps to reproduce:

  • List the exact commands or actions that trigger the issue
  • Include any relevant YAML manifests or configurations

5. Error messages:

  • Full error output from kubectl describe pod <pod-name>
  • Relevant log excerpts from journalctl -u protect-cri or journalctl -u protect-daemon

6. What you’ve tried:

  • Troubleshooting steps you’ve already taken
  • Any changes you made to configuration
  • Whether the issue appeared after an upgrade or configuration change

Example Support Request

Subject: Pods stuck in ContainerCreating with Edera RuntimeClass

Body:

Hi Edera Support,

We're experiencing an issue with pods that use the Edera RuntimeClass.
They get stuck in ContainerCreating state and never transition to Running.

Environment:
- Kubernetes version: 1.32
- Platform: AWS EKS
- Edera AMI: ami-0abc123def456 (us-west-2)
- Node type: t3.medium
- Cluster size: 3 nodes

Problem:
- Started occurring after we rebooted nodes for OS patching
- Affects all pods with runtimeClassName: edera
- Standard pods (without RuntimeClass) work fine

Steps to reproduce:
1. Apply attached pod manifest (test-pod.yaml)
2. Pod remains in ContainerCreating indefinitely

Error output:
kubectl describe pod edera-test shows:
  Warning  FailedCreatePodSandBox  3m (x12 over 15m)  kubelet
  Failed to create pod sandbox: rpc error: code = Unknown desc = failed to start sandbox container

CRI logs (journalctl -u protect-cri -n 50):
[Attached log snippet showing the error]

What we've tried:
- Verified RuntimeClass exists and handler is set to edera
- Confirmed all six Edera services are running
- Restarted protect-cri and protect-daemon services
- Verified kubelet configuration points to Edera CRI socket

Attached:
- Full pod YAML
- Complete CRI logs from the last 30 minutes
- Output of 'protect zone list'

Any guidance would be appreciated. We're blocked on moving
our production workloads to Edera until this is resolved.

Thanks,

This request provides:

  • Clear problem statement
  • Environment context
  • Reproduction steps
  • Error messages
  • What was already tried
  • Relevant attachments

This is everything support needs to help quickly.

Gathering Diagnostic Information

Before contacting support, collect these diagnostics:

Kubernetes Information 

# Cluster version
kubectl version --short > k8s-version.txt

# Node status
kubectl get nodes -o wide > nodes.txt
kubectl describe nodes > nodes-detailed.txt

# RuntimeClass configuration
kubectl get runtimeclass -o yaml > runtimeclass.yaml

# Problem pod details
kubectl describe pod <pod-name> -n <namespace> > pod-describe.txt
kubectl get pod <pod-name> -n <namespace> -o yaml > pod-manifest.yaml

# Events
kubectl get events --all-namespaces --sort-by='.lastTimestamp' > events.txt

Node-Level Information

SSH to the affected node and run:

# Service status
systemctl list-units --type=service | grep protect > services.txt

# Service details
systemctl status protect-cri > cri-status.txt
systemctl status protect-daemon > daemon-status.txt

# Logs
journalctl -u protect-cri --since "1 hour ago" > cri-logs.txt
journalctl -u protect-daemon --since "1 hour ago" > daemon-logs.txt

# Zone list
protect zone list > zones.txt

# Xen hypervisor info
xl list > xl-list.txt
xl info > xl-info.txt

# Node info
uname -a > uname.txt
cat /etc/os-release > os-release.txt

Attach These Files

Include the collected files in your support request. Compress them if sending via email:

tar -czf edera-diagnostics.tar.gz *.txt *.yaml

Response Expectations

Initial response:

  • Typically within a few business hours during business hours
  • Acknowledgment of your issue and any immediate questions

Resolution:

  • Simple issues: Often resolved in the first exchange
  • Complex issues: May require multiple rounds of debugging
  • Critical production issues: Escalated for faster resolution

Feature Requests

Have an idea for how Edera could be better? Share it.

Email: support@edera.dev Subject: “Feature Request: [Brief Description]”

Include:

  • Use case: What problem would this solve?
  • Current workaround: How are you handling it now?
  • Impact: How many users or deployments would benefit?

The team prioritizes feature requests based on customer needs and roadmap priorities.

Training & Consultation

Need more than troubleshooting? Edera offers:

  • Architecture reviews - Validate your deployment design
  • Custom training - Team onboarding and deep dives
  • Migration assistance - Moving existing workloads to Edera

Contact support@edera.dev to discuss your needs.

Community Contributions

Found a bug and fixed it? Built a useful utility? Want to improve documentation?

Contributions welcome:

  • Submit issues and pull requests on GitHub
  • Share scripts and tools with the community
  • Improve documentation or training materials

Reach out to support@edera.dev if you want to contribute.

Module Complete

You now have the knowledge and tools to troubleshoot Edera deployments and know when to reach out for help.

Congratulations! You’ve completed all five modules of Edera 101 Training.

Next Steps

  • Deploy Edera in your environment using the installation guides
  • Apply what you’ve learned to secure your container workloads
  • Share your feedback on this training: Give Feedback
  • Explore advanced topics in the Edera Documentation

Move fast. Don’t break things. Build with Edera.

Last updated on
Helpful Utilities