mirror of
https://github.com/k8sgpt-ai/k8sgpt.git
synced 2026-06-01 15:37:27 +02:00
docs: prepare governance docs for CNCF incubation (#1642)
Build container / Prepare CI Run (push) Has been cancelled
Build container / Build and Push Multi-arch Image (push) Has been cancelled
release / release-please (push) Has been cancelled
release / goreleaser (push) Has been cancelled
release / build-container (push) Has been cancelled
Run tests / build (push) Has been cancelled
Build container / Prepare CI Run (push) Has been cancelled
Build container / Build and Push Multi-arch Image (push) Has been cancelled
release / release-please (push) Has been cancelled
release / goreleaser (push) Has been cancelled
release / build-container (push) Has been cancelled
Run tests / build (push) Has been cancelled
- Add .github/ISSUE_TEMPLATE/ (bug_report, feature_request, config) - Add MAINTAINERS.md with maintainer list and roles - Add GOVERNANCE.md with decision-making, lifecycle, vendor neutrality - Add ADOPTERS.md with adopter collection template - Add ROADMAP.md with current focus areas and planned initiatives - Add INTEGRATIONS.md with CNCF, AI provider, and tool integrations - Add RELEASE.md documenting automated release process Part of CNCF incubation preparation tracking issue #1641 Signed-off-by: Alex Jones <axjns@example.com> Co-authored-by: Alex Jones <axjns@example.com>
This commit is contained in:
Three Foxes (in a Trenchcoat)
committed by
GitHub
GitHub
parent
dfa21ea17d
commit
c82da09984
@@ -0,0 +1,35 @@
|
||||
name: Bug Report
|
||||
about: Report a bug or unexpected behavior
|
||||
title: "bug: "
|
||||
labels: ["bug"]
|
||||
assignees: []
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
Before creating a bug report, please search existing issues and check the documentation at https://docs.k8sgpt.ai
|
||||
-->
|
||||
|
||||
## Expected Behavior
|
||||
<!-- Briefly describe what you expected to happen -->
|
||||
|
||||
## Current Behavior
|
||||
<!-- Describe what happened instead -->
|
||||
|
||||
## Steps to Reproduce
|
||||
<!-- Provide detailed steps to reproduce the bug -->
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
4.
|
||||
|
||||
## Environment
|
||||
<!-- Provide relevant environment details -->
|
||||
|
||||
- **k8sgpt version:** (e.g., `k8sgpt version` output)
|
||||
- **Kubernetes version:** (e.g., `kubectl version --short`)
|
||||
- **AI Backend/Provider:** (e.g., OpenAI, Ollama, Azure)
|
||||
- **OS/Platform:** (e.g., macOS, Ubuntu, Windows)
|
||||
|
||||
## Additional Context
|
||||
<!-- Add any other context about the problem here (logs, screenshots, config snippets) -->
|
||||
@@ -0,0 +1,11 @@
|
||||
blank_issues_enabled: false
|
||||
contact_links:
|
||||
- name: k8sgpt Documentation
|
||||
url: https://docs.k8sgpt.ai
|
||||
about: Please check the documentation before opening an issue
|
||||
- name: Slack Community
|
||||
url: https://join.slack.com/t/k8sgpt/shared_invite/zt-332vhyaxv-bfjJwHZLXWVCB3QaXafEYQ
|
||||
about: Join our Slack community to ask questions and get help
|
||||
- name: Security Vulnerabilities
|
||||
url: https://github.com/k8sgpt-ai/k8sgpt/blob/main/SECURITY.md
|
||||
about: Please report security vulnerabilities according to our security policy
|
||||
@@ -0,0 +1,22 @@
|
||||
name: Feature Request
|
||||
about: Suggest a new feature or enhancement
|
||||
title: "feat: "
|
||||
labels: ["enhancement"]
|
||||
assignees: []
|
||||
|
||||
---
|
||||
|
||||
## Is your feature request related to a problem?
|
||||
<!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when -->
|
||||
|
||||
## Describe the solution you'd like
|
||||
<!-- A clear and concise description of what you want to happen -->
|
||||
|
||||
## Describe alternatives you've considered
|
||||
<!-- A clear and concise description of any alternative solutions or features you've considered -->
|
||||
|
||||
## Additional context
|
||||
<!-- Add any other context, screenshots, or references to similar tools here -->
|
||||
|
||||
## Would you be willing to help implement this?
|
||||
<!-- Let us know if you're interested in contributing -->
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
# Adopters
|
||||
|
||||
This file lists organizations that are adopting k8sgpt. If your organization uses k8sgpt, please add yourself!
|
||||
|
||||
## How to Add Your Organization
|
||||
|
||||
Open a pull request to add your organization to this list. Include:
|
||||
- Organization name
|
||||
- Website (optional)
|
||||
- Level of adoption (Development, Trial, Production)
|
||||
- Brief description of use case (optional)
|
||||
|
||||
## Adopters
|
||||
|
||||
### Production
|
||||
|
||||
| Organization | Website | Level | Description |
|
||||
|-------------|---------|-------|-------------|
|
||||
| _(Add your organization here)_ | | | |
|
||||
|
||||
### Development / Trialing
|
||||
|
||||
| Organization | Website | Level | Description |
|
||||
|-------------|---------|-------|-------------|
|
||||
| _(Add your organization here)_ | | | |
|
||||
|
||||
## Verified Adopters
|
||||
|
||||
The following organizations have been verified by the TOC during the incubation process:
|
||||
|
||||
| Organization | Adoption Level | Verified By | Date |
|
||||
|-------------|----------------|-------------|------|
|
||||
| _(TBD)_ | | | |
|
||||
|
||||
> **Note:** For incubation, the TOC requires at least 3 independent adopters in dev/test or production. Please reach out if you'd like to be included in the verified list.
|
||||
|
||||
## Need Help Getting Started?
|
||||
|
||||
- [Documentation](https://docs.k8sgpt.ai)
|
||||
- [Quick Start Guide](https://docs.k8sgpt.ai/getting-started/getting-started/)
|
||||
- [Slack Community](https://join.slack.com/t/k8sgpt/shared_invite/zt-332vhyaxv-bfjJwHZLXWVCB3QaXafEYQ)
|
||||
@@ -0,0 +1,479 @@
|
||||
# General Technical Review - k8sgpt / Incubation
|
||||
|
||||
- **Project:** https://github.com/k8sgpt-ai/k8sgpt
|
||||
- **Project Version:** v0.4.32
|
||||
- **Website:** https://k8sgpt.ai
|
||||
- **Date Updated:** 2026-04-24
|
||||
- **Template Version:** v1.0
|
||||
- **Description:** k8sgpt is a tool for scanning Kubernetes clusters, diagnosing, and triaging issues in simple English. It has SRE experience codified into analyzers and helps pull out the most relevant information, enriching it with AI from various LLM providers.
|
||||
|
||||
---
|
||||
|
||||
## Day 0 - Planning Phase
|
||||
|
||||
### Scope
|
||||
|
||||
**Describe the roadmap process, how scope is determined for mid to long term features, as well as how the roadmap maps back to current contributions and maintainer ladder?**
|
||||
|
||||
The roadmap is documented in [ROADMAP.md](https://github.com/k8sgpt-ai/k8sgpt/blob/main/ROADMAP.md). Scope is determined through:
|
||||
- GitHub Issues and PRs from the community
|
||||
- Slack discussions in [#k8sgpt](https://join.slack.com/t/k8sgpt/shared_invite/zt-332vhyaxv-bfjJwHZLXWVCB3QaXafEYQ)
|
||||
- GitHub Discussions
|
||||
- Maintainer retrospectives and planning sessions
|
||||
|
||||
Contributions follow a clear ladder documented in [GOVERNANCE.md](https://github.com/k8sgpt-ai/k8sgpt/blob/main/GOVERNANCE.md): contributors → approvers → maintainers. Roadmap items are prioritized by maintainer consensus, with feature requests evaluated through GitHub issues.
|
||||
|
||||
**Describe the target persona or user(s) for the project?**
|
||||
|
||||
- **Junior SREs / DevOps Engineers** who need help diagnosing Kubernetes issues but lack deep domain expertise
|
||||
- **Experienced SREs** who want to accelerate their troubleshooting workflow
|
||||
- **Platform Engineering Teams** who want continuous cluster monitoring via the operator
|
||||
- **Kubernetes Educators** who use k8sgpt to teach cluster health concepts
|
||||
- **Dev Teams** who need quick insights into cluster issues without waiting for SRE availability
|
||||
|
||||
**Explain the primary use case for the project. What additional use cases are supported by the project?**
|
||||
|
||||
- **Primary:** Real-time cluster diagnostics — scan a Kubernetes cluster and get AI-powered explanations of issues in plain English
|
||||
- **Additional:**
|
||||
- Continuous monitoring via k8sgpt operator
|
||||
- Slack/Teams integration for alerting
|
||||
- Prometheus/Alertmanager integration for monitoring
|
||||
- Custom analyzer framework for extensibility
|
||||
- MCP server integration for AI assistant workflows
|
||||
|
||||
**Explain which use cases have been identified as unsupported by the project.**
|
||||
|
||||
- k8sgpt does not modify or remediate cluster state (read-only by design)
|
||||
- k8sgpt does not replace comprehensive security scanning tools (focuses on operational issues, not security posture)
|
||||
- k8sgpt does not provide its own AI model (consumes external AI APIs)
|
||||
- k8sgpt does not persistently store cluster data (except optional remote caching)
|
||||
|
||||
**Describe the intended types of organizations who would benefit from adopting this project.**
|
||||
|
||||
- Financial services organizations needing SRE-grade diagnostics
|
||||
- Cloud-native software manufacturers
|
||||
- Organizations providing platform engineering services
|
||||
- Managed Kubernetes providers
|
||||
- Education and training organizations
|
||||
- Any organization running Kubernetes at any scale
|
||||
|
||||
**Please describe any completed end user research and link to any reports.**
|
||||
|
||||
End user feedback is gathered through:
|
||||
- Slack community discussions (#k8sgpt)
|
||||
- GitHub Issues and PRs
|
||||
- Product Hunt user feedback
|
||||
- KubeCon and CNCF event discussions
|
||||
|
||||
No formal end user research reports have been published yet, but the project maintains detailed issue tracking that captures user pain points and feature requests.
|
||||
|
||||
### Usability
|
||||
|
||||
**How should the target personas interact with your project?**
|
||||
|
||||
- **CLI users:** Install via Homebrew, install kubectl plugin via Krew, or download binary. Run `k8sgpt analyze --explain` for instant diagnostics.
|
||||
- **Operator users:** Deploy via Helm chart for continuous monitoring with Prometheus/Alertmanager integration.
|
||||
- **Developer users:** Use the custom analyzer framework to write extensible analyzers in any language (Rust, Go, Python, etc.).
|
||||
- **AI assistant users:** Connect via MCP server to Claude Desktop, ChatGPT, or other MCP-compatible clients.
|
||||
|
||||
**Describe the user experience (UX) and user interface (UI) of the project.**
|
||||
|
||||
k8sgpt provides:
|
||||
- **CLI:** Clean terminal output with color-coded results, table formatting, and JSON export. The `--explain` flag provides natural language AI-powered explanations.
|
||||
- **Operator:** Passive background monitoring with no interactive UI. Results flow through Prometheus metrics and Alertmanager alerts.
|
||||
- **Web interface:** The [documentation site](https://docs.k8sgpt.ai) provides comprehensive guides and reference materials.
|
||||
|
||||
**Describe how this project integrates with other projects in a production environment.**
|
||||
|
||||
k8sgpt integrates with:
|
||||
- **Prometheus/Alertmanager:** Export analysis results as metrics and send alerts
|
||||
- **Slack/Discord/Teams:** Send analysis results to chat channels
|
||||
- **Helm:** Deploy via standard Helm charts
|
||||
- **ArgoCD/FluxCD:** Compatible with GitOps workflows
|
||||
- **MCP:** Server integration for AI assistants
|
||||
- **Custom analyzers:** HTTP-based external analyzers for extensibility
|
||||
|
||||
### Design
|
||||
|
||||
**Explain the design principles and best practices the project is following.**
|
||||
|
||||
- **Vendor neutrality:** Support for 13+ AI backends (OpenAI, Azure, Cohere, Ollama, Amazon Bedrock, Google Gemini, etc.)
|
||||
- **Read-only operation:** Never modifies cluster state, reducing risk
|
||||
- **Anonymization:** Sensitive data masked before sending to AI backends
|
||||
- **Extensibility:** Plugin-style analyzer framework for custom analyzers
|
||||
- **Convention over configuration:** Sensible defaults, optional overrides
|
||||
- **Modular architecture:** Analyzers are independent and composable
|
||||
|
||||
**Outline or link to the project's architecture requirements? Describe how they differ for Proof of Concept, Development, Test and Production environments, as applicable.**
|
||||
|
||||
k8sgpt has a single deployment model that works across all environments:
|
||||
- **PoC/Dev:** Install CLI, point at any kubeconfig, run analysis
|
||||
- **Test:** Same as Dev, with custom analyzers and filters
|
||||
- **Production:** Deploy operator via Helm, configure continuous monitoring, integrate with monitoring/alerting tools
|
||||
|
||||
The architecture does not change between environments — only the configuration and deployment method differs.
|
||||
|
||||
**Define any specific service dependencies the project relies on in the cluster.**
|
||||
|
||||
k8sgpt has no in-cluster service dependencies. It reads directly from the Kubernetes API server. Optional integrations (Prometheus, Slack, custom analyzers) are external services that the user configures.
|
||||
|
||||
**Describe how the project implements Identity and Access Management.**
|
||||
|
||||
- Uses the user's existing kubeconfig for cluster authentication (in-cluster or local)
|
||||
- No additional IAM roles or service accounts required
|
||||
- Operator runs as a standard Kubernetes deployment with RBAC permissions for read-only access to cluster resources
|
||||
- AI backend API keys are managed by the user and stored locally
|
||||
|
||||
**Describe how the project has addressed sovereignty.**
|
||||
|
||||
- Local AI options (Ollama, LocalAI) keep data within the user's network
|
||||
- Users can configure any AI backend including self-hosted models
|
||||
- Anonymization feature masks sensitive data before sending to external AI providers
|
||||
- Remote caching (S3, Azure Blob, GCS) can be configured with user-controlled storage
|
||||
|
||||
**Describe any compliance requirements addressed by the project.**
|
||||
|
||||
- Apache 2.0 license compliance
|
||||
- CNCF Code of Conduct
|
||||
- OpenSSF Best Practices badge
|
||||
- Developer Certificate of Origin (DCO) enforced on all commits
|
||||
- FOSSA license scanning in CI
|
||||
|
||||
**Describe the project's High Availability requirements.**
|
||||
|
||||
k8sgpt is a stateless tool:
|
||||
- **CLI:** Single-process, no HA requirements
|
||||
- **Operator:** Standard Kubernetes deployment with configurable replicas. No leader election needed for basic operation.
|
||||
- **MCP server:** Stateless HTTP server, can be horizontally scaled
|
||||
|
||||
**Describe the project's resource requirements, including CPU, Network and Memory.**
|
||||
|
||||
- **CLI:** ~50MB memory, minimal CPU (analysis time depends on cluster size and AI backend response time)
|
||||
- **Operator:** ~100MB memory, minimal CPU (periodic scanning)
|
||||
- **Network:** Outbound HTTPS to AI backend (when using --explain flag), outbound to Kubernetes API
|
||||
- **Storage:** Config file (~1KB), optional remote caching (user-configured)
|
||||
|
||||
**Describe the project's storage requirements, including its use of ephemeral and/or persistent storage.**
|
||||
|
||||
- **Ephemeral:** No persistent storage required. Config stored locally.
|
||||
- **Optional:** Remote caching (S3, Azure Blob, GCS) for analysis results
|
||||
- **Operator:** No persistent volumes required
|
||||
|
||||
**Please outline the project's API Design:**
|
||||
|
||||
- **Kubernetes API:** Read-only access to standard Kubernetes resources (Pods, Deployments, Services, etc.)
|
||||
- **AI Backend API:** Standard REST/HTTP API following OpenAI chat completion format
|
||||
- **Custom Analyzer API:** gRPC-based protocol defined in [schema](https://github.com/k8sgpt-ai/schemas/blob/main/protobuf/schema/v1/custom_analyzer.proto)
|
||||
- **MCP Server:** Model Context Protocol for AI assistant integration
|
||||
- **Release API:** Automated via release-please and GoReleaser
|
||||
|
||||
**Describe the project's release processes, including major, minor and patch releases.**
|
||||
|
||||
Documented in [RELEASE.md](https://github.com/k8sgpt-ai/k8sgpt/blob/main/RELEASE.md):
|
||||
- Automated via release-please (tracks conventional commits) and GoReleaser
|
||||
- Monthly release cadence
|
||||
- Semantic versioning (MAJOR.MINOR.PATCH)
|
||||
- Binaries, container images, Helm charts, Homebrew packages, RPM/DEB/APK packages
|
||||
|
||||
### Installation
|
||||
|
||||
**Describe how the project is installed and initialized, e.g. a minimal install with a few lines of code or does it require more complex integration and configuration?**
|
||||
|
||||
- **CLI:** `brew install k8sgpt` or download binary — requires only an AI API key (`k8sgpt auth add`)
|
||||
- **Operator:** `helm install k8sgpt-operator k8sgpt-ai/k8sgpt` — requires AI backend configuration
|
||||
- **MCP:** `k8sgpt serve --mcp` — zero configuration needed
|
||||
|
||||
**How does an adopter test and validate the installation?**
|
||||
|
||||
Run `k8sgpt analyze --explain` to verify the tool connects to the cluster and produces analysis results. The operator can be validated by checking Pod status and Prometheus metrics.
|
||||
|
||||
### Security
|
||||
|
||||
**Please provide a link to the project's cloud native security self assessment.**
|
||||
|
||||
[SECURITY_SELF_ASSESSMENT.md](https://github.com/k8sgpt-ai/k8sgpt/blob/main/SECURITY_SELF_ASSESSMENT.md)
|
||||
|
||||
**Please review the Cloud Native Security Tenets from TAG Security.**
|
||||
|
||||
k8sgpt satisfies these cloud native security tenets:
|
||||
- **Secure by default:** Anonymization is enabled by default, read-only access is the default mode
|
||||
- **Least privilege:** Only reads cluster state, no write operations
|
||||
- **Defense in depth:** Multiple layers of security (anonymization, TLS, RBAC, DCO, OpenSSF badge)
|
||||
- **Transparency:** All code is open source, security policy is documented
|
||||
|
||||
**Describe how each of the cloud native principles apply to your project.**
|
||||
|
||||
- **Secure by default:** Sensitive data is masked before AI queries
|
||||
- **Least privilege:** Read-only Kubernetes API access
|
||||
- **Zero trust:** Each AI backend call is authenticated independently
|
||||
- **Defense in depth:** Multiple security layers (anonymization, TLS, RBAC, DCO, OpenSSF)
|
||||
|
||||
**How do you recommend users alter security defaults in order to "loosen" the security of the project?**
|
||||
|
||||
Users who need to send unmasked data to AI backends can disable anonymization. Users who need write access should use k8sgpt as a read-only tool and implement remediation through separate Kubernetes admission controllers or operators.
|
||||
|
||||
**Security Hygiene**
|
||||
|
||||
- **Frameworks/practices:** Go modules with strict versioning, Renovate for automated dependency updates, golangci-lint, DCO enforcement, CODEOWNERS for PR review
|
||||
- **Security risk evaluation:** All analyzers are reviewed for data exposure. Known risks (event message masking) are tracked in GitHub issues.
|
||||
|
||||
**Cloud Native Threat Modeling**
|
||||
|
||||
- **Least privilege:** k8sgpt only reads from the Kubernetes API. No write operations, no cluster modifications.
|
||||
- **Certificate rotation:** Not applicable — k8sgpt does not manage certificates. Uses standard Kubernetes API TLS.
|
||||
- **Secure software supply chain:** SBOM generated via Syft in release workflow. Renovate for automated dependency updates. OpenSSF Best Practices badge.
|
||||
|
||||
## Day 1 - Installation and Deployment Phase
|
||||
|
||||
### Project Installation and Configuration
|
||||
|
||||
**Describe what project installation and configuration look like.**
|
||||
|
||||
- **CLI:** `brew install k8sgpt` → `k8sgpt auth add --backend openai` → `k8sgpt analyze --explain`
|
||||
- **Operator:** Helm chart with configurable AI backends, analyzers, and integrations
|
||||
- **Custom analyzers:** gRPC-based HTTP service + k8sgpt config
|
||||
|
||||
### Project Enablement and Rollback
|
||||
|
||||
**How can this project be enabled or disabled in a live cluster?**
|
||||
|
||||
- **CLI:** No enable/disable needed — run when needed
|
||||
- **Operator:** `helm upgrade --set enabled=false` or `helm uninstall`
|
||||
|
||||
**Describe how enabling the project changes any default behavior of the cluster or running workloads.**
|
||||
|
||||
k8sgpt is purely read-only. It has no impact on cluster behavior or running workloads.
|
||||
|
||||
**Describe how the project tests enablement and disablement.**
|
||||
|
||||
CI tests cover both CLI and operator modes. The operator is tested with Minikube and Kind clusters.
|
||||
|
||||
**How does the project clean up any resources created, including CRDs?**
|
||||
|
||||
The operator creates no persistent resources. Helm uninstall removes all resources. CLI creates no cluster resources.
|
||||
|
||||
### Rollout, Upgrade and Rollback Planning
|
||||
|
||||
**How does the project intend to provide and maintain compatibility with infrastructure and orchestration management tools like Kubernetes and with what frequency?**
|
||||
|
||||
- Uses client-go for Kubernetes API interaction
|
||||
- Tests against current and previous 2 Kubernetes versions
|
||||
- Monthly release cadence ensures timely updates
|
||||
|
||||
**Describe how the project handles rollback procedures.**
|
||||
|
||||
- **CLI:** Rollback via `brew upgrade k8sgpt@previous` or downloading previous binary
|
||||
- **Operator:** `helm rollback` to previous release
|
||||
- **Container images:** Rollback via image tag
|
||||
|
||||
**How can a rollout or rollback fail? Describe any impact to already running workloads.**
|
||||
|
||||
No impact on running workloads — k8sgpt is read-only. Rollback failures would only affect k8sgpt's ability to function, not cluster operations.
|
||||
|
||||
**Describe any specific metrics that should inform a rollback.**
|
||||
|
||||
- Operator crash loops
|
||||
- Analysis result quality degradation
|
||||
- AI backend API errors
|
||||
|
||||
**Explain how upgrades and rollbacks were tested.**
|
||||
|
||||
Each release includes CI tests against multiple Kubernetes versions. Operator tests run in Kind and Minikube environments.
|
||||
|
||||
**Explain how the project informs users of deprecations and removals of features and APIs.**
|
||||
|
||||
- Changelog in GitHub Releases
|
||||
- Deprecation warnings in CLI output
|
||||
- Documentation updates on docs.k8sgpt.ai
|
||||
|
||||
**Explain how the project permits utilization of alpha and beta capabilities as part of a rollout.**
|
||||
|
||||
k8sgpt uses only stable Kubernetes API versions. Custom analyzers can leverage alpha APIs if users configure them to do so.
|
||||
|
||||
## Day 2 - Day-to-Day Operations Phase
|
||||
|
||||
### Scalability/Reliability
|
||||
|
||||
**Describe how the project increases the size or count of existing API objects.**
|
||||
|
||||
Not applicable — k8sgpt is a read-only analysis tool, not a controller that manages API objects.
|
||||
|
||||
**Describe how the project defines Service Level Objectives (SLOs) and Service Level Indicators (SLIs).**
|
||||
|
||||
- **SLO:** Analysis completion within expected timeframes (varies by cluster size and AI backend)
|
||||
- **SLI:** Percentage of successful analysis runs, error rates, AI backend response times
|
||||
|
||||
**Describe any operations that will increase in time covered by existing SLIs/SLOs.**
|
||||
|
||||
Larger clusters and more analyzers increase analysis time proportionally. The operator can be configured to scan namespaces independently.
|
||||
|
||||
**Describe the increase in resource usage in any components as a result of enabling this project.**
|
||||
|
||||
- **CLI:** ~50MB memory, minimal CPU
|
||||
- **Operator:** ~100MB memory, minimal CPU
|
||||
- **Network:** Outbound HTTPS to AI backend per analysis
|
||||
|
||||
**Describe which conditions enabling / using this project would result in resource exhaustion.**
|
||||
|
||||
Not applicable — k8sgpt is read-only and does not create persistent resources.
|
||||
|
||||
**Describe the load testing that has been performed on the project and the results.**
|
||||
|
||||
Load testing is performed by the community during development. The project scales to clusters with 1000+ nodes. Operator scanning is configurable for different intervals.
|
||||
|
||||
**Describe the recommended limits of users, requests, system resources, etc.**
|
||||
|
||||
No hard limits. The CLI works with any cluster size. The operator is recommended for clusters with 100+ nodes where continuous monitoring is valuable.
|
||||
|
||||
**Describe which resilience pattern the project uses.**
|
||||
|
||||
- **CLI:** Stateless, no circuit breaker needed
|
||||
- **Operator:** Standard Kubernetes deployment with health checks
|
||||
- **AI backends:** Multiple backend support provides natural fallback
|
||||
|
||||
### Observability Requirements
|
||||
|
||||
**Describe the signals the project is using or producing, including logs, metrics, profiles and traces.**
|
||||
|
||||
- **Logs:** Standard Kubernetes operator logging (info, warn, error levels)
|
||||
- **Metrics:** Prometheus-compatible metrics for operator mode (analysis duration, error rates)
|
||||
- **Traces:** Not currently implemented, but the architecture supports it
|
||||
- **Formats:** JSON logs, Prometheus exposition format
|
||||
|
||||
**Describe how the project captures audit logging.**
|
||||
|
||||
k8sgpt does not modify cluster state, so audit logging is not applicable. The Kubernetes API server audit logs capture all k8sgpt read operations.
|
||||
|
||||
**Describe any dashboards the project uses or implements.**
|
||||
|
||||
k8sgpt does not include built-in dashboards, but integrates with:
|
||||
- **Prometheus:** Metrics can be visualized in Grafana
|
||||
- **Custom integrations:** Slack, Teams for alerting
|
||||
|
||||
**Describe how the project surfaces project resource requirements for adopters to monitor cloud and infrastructure costs.**
|
||||
|
||||
k8sgpt has minimal resource requirements (~100MB memory for operator). No persistent storage needed. Cost tracking is via standard Kubernetes resource monitoring.
|
||||
|
||||
**Which parameters is the project covering to ensure the health of the application/service and its workloads?**
|
||||
|
||||
k8sgpt's analyzers cover:
|
||||
- Pod health (crash loops, OOM, failed states)
|
||||
- Deployment status (replicas, rollout status)
|
||||
- Service connectivity
|
||||
- Resource limits and requests
|
||||
- Storage issues
|
||||
- Network policy violations
|
||||
- Security misconfigurations
|
||||
|
||||
**How can an operator determine if the project is in use by workloads?**
|
||||
|
||||
k8sgpt is a monitoring tool, not a workload. Operators can check:
|
||||
- k8sgpt Pod status (operator mode)
|
||||
- Analysis result metrics (Prometheus)
|
||||
- Slack/Teams alert channels
|
||||
|
||||
**How can someone using this project know that it is working for their instance?**
|
||||
|
||||
Run `k8sgpt analyze --explain` and verify analysis results are returned. For the operator, check the logs and Prometheus metrics.
|
||||
|
||||
**Describe the SLOs (Service Level Objectives) for this project.**
|
||||
|
||||
- **Availability:** k8sgpt CLI is always available (local tool). Operator availability depends on Kubernetes deployment.
|
||||
- **Performance:** Analysis completes within expected timeframes based on cluster size and AI backend response time.
|
||||
- **Accuracy:** Analyzer results are based on well-established Kubernetes failure patterns.
|
||||
|
||||
**What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?**
|
||||
|
||||
- Operator Pod health (running, not crash-looping)
|
||||
- Analysis completion rate
|
||||
- Error rate from AI backends
|
||||
- Time between analysis scans (operator mode)
|
||||
|
||||
### Dependencies
|
||||
|
||||
**Describe the specific running services the project depends on in the cluster.**
|
||||
|
||||
k8sgpt has no in-cluster dependencies. It reads directly from the Kubernetes API server.
|
||||
|
||||
**Describe the project's dependency lifecycle policy.**
|
||||
|
||||
- Automated via Renovate with auto-merge for non-major updates
|
||||
- Go modules with strict version pinning
|
||||
- Monthly release cadence ensures timely dependency updates
|
||||
- Security vulnerabilities tracked via OpenSSF badge and FOSSA
|
||||
|
||||
**How does the project incorporate and consider source composition analysis as part of its development and security hygiene?**
|
||||
|
||||
- FOSSA license scanning in CI
|
||||
- Renovate for automated dependency tracking
|
||||
- SBOM generated via Syft in release workflow
|
||||
- OpenSSF Best Practices badge
|
||||
|
||||
**Describe how the project implements changes based on source composition analysis (SCA) and the timescale.**
|
||||
|
||||
- FOSSA findings are reviewed and addressed within the next release cycle
|
||||
- Critical security vulnerabilities in dependencies are patched immediately
|
||||
- Non-critical license issues are addressed within 30 days
|
||||
|
||||
### Troubleshooting
|
||||
|
||||
**How does this project recover if a key component or feature becomes unavailable?**
|
||||
|
||||
- **AI backend unavailable:** Use `--explain=false` to get raw analysis without AI explanations
|
||||
- **Multiple backends:** Configure fallback backends
|
||||
- **Kubernetes API:** Standard client-go retry logic handles temporary API server unavailability
|
||||
|
||||
**Describe the known failure modes.**
|
||||
|
||||
- AI backend API rate limits or outages (mitigated by local models or caching)
|
||||
- Large cluster analysis may take longer than expected (mitigated by namespace filtering)
|
||||
- Event message anonymization is not yet complete (tracked in issue #560)
|
||||
|
||||
### Compliance
|
||||
|
||||
**What steps does the project take to ensure that all third-party code and components have correct and complete attribution and license notices?**
|
||||
|
||||
- Apache 2.0 license file in repository root
|
||||
- LICENSE in all subdirectories
|
||||
- FOSSA license scanning in CI
|
||||
- Go modules with license metadata
|
||||
- Copyright headers in source files
|
||||
|
||||
**Describe how the project ensures alignment with CNCF recommendations for attribution notices.**
|
||||
|
||||
- Standard Go module attribution
|
||||
- LICENSE files in all packages
|
||||
- FOSSA license compliance scanning
|
||||
- Copyright headers in source files following Apache 2.0 conventions
|
||||
|
||||
## Day 2 - Security
|
||||
|
||||
### Security Hygiene
|
||||
|
||||
**How is the project executing access control?**
|
||||
|
||||
- GitHub CODEOWNERS enforces PR review requirements
|
||||
- Maintainer team (7 members) with clear roles and responsibilities
|
||||
- DCO enforcement on all commits
|
||||
- Branch protection requires PR review and passing CI
|
||||
- GitHub organization membership controls write access
|
||||
|
||||
### Cloud Native Threat Modeling
|
||||
|
||||
**How does the project ensure its security reporting and response team is representative of its community diversity (organizational and individual)?**
|
||||
|
||||
The maintainer team includes contributors from:
|
||||
- AWS (AlexsJones)
|
||||
- Agicap (matthisholleville)
|
||||
- DaoCloud (yankay)
|
||||
- @basiqio (bradmccoydev)
|
||||
- Independent contributors (thschue, AnaisUrlichs, roberthstrand, rakshitgondwal)
|
||||
|
||||
**How does the project invite and rotate security reporting team members?**
|
||||
|
||||
Security reports are handled via:
|
||||
- Email: contact@k8sgpt.ai
|
||||
- Slack: Any maintainer in #k8sgpt
|
||||
- GitHub Security Advisories
|
||||
|
||||
Any maintainer can respond to security reports. The process is documented in SECURITY.md and the security self-assessment.
|
||||
+107
@@ -0,0 +1,107 @@
|
||||
# k8sgpt Governance
|
||||
|
||||
This document describes how k8sgpt is governed and how decisions are made.
|
||||
|
||||
## Principles
|
||||
|
||||
k8sgpt operates under the following principles:
|
||||
|
||||
- **Open**: k8sgpt is open source. All changes to the project are made publicly.
|
||||
- **Neutral**: k8sgpt is vendor-neutral. No single organization controls the project.
|
||||
- **Collaborative**: We welcome contributions from all individuals and organizations.
|
||||
- **Merit-based**: Influence is earned through sustained, quality contributions.
|
||||
- **Community-focused**: We serve the cloud native community, not any single vendor.
|
||||
|
||||
k8sgpt is a CNCF project and adheres to the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
|
||||
|
||||
## Decision Making
|
||||
|
||||
### Consensus-Seeking
|
||||
|
||||
The project strives for consensus among maintainers. For most decisions:
|
||||
1. A proposal is made (via GitHub issue or PR)
|
||||
2. Maintainers review and discuss for at least 48 hours
|
||||
3. If consensus is reached, the proposal is implemented
|
||||
4. If consensus cannot be reached, the proposal is put to a vote
|
||||
|
||||
### Voting
|
||||
|
||||
When consensus cannot be reached on significant matters:
|
||||
- Each maintainer receives one vote
|
||||
- A simple majority (50% + 1) decides the outcome
|
||||
- Quorum requires at least 50% of active maintainers to participate
|
||||
- Ties are broken by the project lead (AlexsJones)
|
||||
|
||||
### Significant Decisions
|
||||
|
||||
The following require a formal vote:
|
||||
- Addition or removal of maintainers
|
||||
- Changes to this governance document
|
||||
- Project direction changes (e.g., major architectural shifts)
|
||||
- Deprecation or removal of core features
|
||||
- Licensing changes
|
||||
|
||||
### Operational Decisions
|
||||
|
||||
Minor operational decisions (bug fixes, documentation, small features) do not require a full vote and can be handled through normal PR review.
|
||||
|
||||
## Maintainer Lifecycle
|
||||
|
||||
### Becoming a Maintainer
|
||||
|
||||
1. Make sustained, quality contributions over a period of at least 3 months
|
||||
2. Be nominated by an existing maintainer
|
||||
3. Receive approval from a majority of current maintainers
|
||||
4. Be added to the [MAINTAINERS.md](MAINTAINERS.md) file and granted write access
|
||||
|
||||
### Stepping Down
|
||||
|
||||
Maintainers may step down at any time by notifying the remaining maintainers. Stepping-down maintainers are listed in the [Emeritus Maintainers](#emeritus-maintainers) section of MAINTAINERS.md.
|
||||
|
||||
### Inactive Maintainers
|
||||
|
||||
A maintainer who has not contributed (code, review, or community) for 6 months may be asked to step down. If they do not respond within 30 days, the remaining maintainers may vote to move them to emeritus status.
|
||||
|
||||
### Revocation
|
||||
|
||||
A maintainer's access may be revoked for violations of the CNCF Code of Conduct. This requires a supermajority (2/3) vote of active maintainers.
|
||||
|
||||
## Vendor Neutrality
|
||||
|
||||
k8sgpt is committed to vendor neutrality:
|
||||
|
||||
- No single vendor may control project direction
|
||||
- All AI backend providers are supported equally (OpenAI, Azure, Cohere, Ollama, Amazon Bedrock, Google Gemini, etc.)
|
||||
- Decisions about supported backends are made based on community merit, not vendor influence
|
||||
- Financial contributions from sponsors do not buy decision-making power
|
||||
- The project benefits from the CNCF's neutral governance structure
|
||||
|
||||
## Subproject Governance
|
||||
|
||||
k8sgpt has several subprojects under the [k8sgpt-ai organization](https://github.com/k8sgpt-ai):
|
||||
|
||||
- **k8sgpt** (main project) - This repository
|
||||
- **k8sgpt-operator** - Kubernetes operator for continuous monitoring
|
||||
- **docs** - Documentation site
|
||||
- **charts** - Helm charts
|
||||
- **website** - Project website
|
||||
- **community** - Community management
|
||||
|
||||
Subprojects have their own maintainers but are expected to align with the main project's governance. Changes to a subproject's governance should be coordinated with the main project maintainers.
|
||||
|
||||
## Community Engagement
|
||||
|
||||
We encourage broad community participation:
|
||||
|
||||
- **Slack**: [#k8sgpt](https://join.slack.com/t/k8sgpt/shared_invite/zt-332vhyaxv-bfjJwHZLXWVCB3QaXafEYQ)
|
||||
- **GitHub Issues**: All feature requests and bug reports
|
||||
- **GitHub Discussions**: Open for community questions and ideas
|
||||
- **CNCF Slack**: [#k8sgpt](https://slack.cncf.io/)
|
||||
|
||||
## Code of Conduct
|
||||
|
||||
All participants in this project are expected to adhere to the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). Reports should be sent to the project maintainers and/or CNCF staff.
|
||||
|
||||
## Amendment Process
|
||||
|
||||
This governance document may be amended at any time by a supermajority (2/3) vote of active maintainers. Proposed amendments should be discussed publicly before voting.
|
||||
@@ -0,0 +1,62 @@
|
||||
# Integrations
|
||||
|
||||
k8sgpt integrates with a variety of cloud native tools, platforms, and services.
|
||||
|
||||
## CNCF Project Integrations
|
||||
|
||||
| Project | Integration Type | Description |
|
||||
|---------|-----------------|-------------|
|
||||
| [Prometheus](https://prometheus.io/) | Exporter / Metrics | k8sgpt operator can export analysis results to Prometheus for monitoring |
|
||||
| [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator) | Operator Integration | Integration with Prometheus Operator for service discovery and alerting |
|
||||
| [Alertmanager](https://prometheus.io/docs/alerting/alertmanager/) | Alert Integration | Send k8sgpt analysis alerts to Alertmanager |
|
||||
| [OpenTelemetry](https://opentelemetry.io/) | Observability | Export analysis metrics and traces via OpenTelemetry |
|
||||
| [Grafana](https://grafana.com/) | Dashboard | Visualize k8sgpt analysis results in Grafana dashboards |
|
||||
| [Kubernetes](https://kubernetes.io/) | Core Platform | Native Kubernetes resource analysis and diagnostics |
|
||||
| [Helm](https://helm.sh/) | Packaging | k8sgpt available as a Helm chart in the [charts](https://github.com/k8sgpt-ai/charts) repository |
|
||||
| [Krew](https://krew.dev/) | Plugin Distribution | k8sgpt distributed as a Krew kubectl plugin via [.krew.yaml](https://github.com/k8sgpt-ai/k8sgpt/blob/main/.krew.yaml) |
|
||||
|
||||
## AI/LLM Provider Integrations
|
||||
|
||||
| Provider | Backend Name | Description |
|
||||
|----------|-------------|-------------|
|
||||
| [OpenAI](https://openai.com/) | `openai` | Default provider - supports GPT-3.5, GPT-4, and other OpenAI models |
|
||||
| [Azure OpenAI](https://azure.microsoft.com/services/openai/) | `azureopenai` | Azure-hosted OpenAI models |
|
||||
| [Cohere](https://cohere.com/) | `cohere` | Cohere's command models |
|
||||
| [Amazon Bedrock](https://aws.amazon.com/bedrock/) | `amazonbedrock` | AWS Bedrock - supports Claude, Llama, Titan, and more |
|
||||
| [Amazon SageMaker](https://aws.amazon.com/sagemaker/) | `amazonsagemaker` | AWS SageMaker JumpStart models |
|
||||
| [Google Gemini](https://ai.google/gemini) | `google` | Google's Gemini models |
|
||||
| [Google Vertex AI](https://cloud.google.com/vertex-ai) | `googlevertexai` | Google Cloud Vertex AI models |
|
||||
| [Ollama](https://ollama.com/) | `ollama` | Local LLM inference with Ollama |
|
||||
| [LocalAI](https://localai.io/) | `localai` | Self-hosted OpenAI-compatible API |
|
||||
| [Hugging Face](https://huggingface.co/) | `huggingface` | Hugging Face Inference API |
|
||||
| [IBM WatsonX](https://www.ibm.com/watsonx) | `watsonxai` | IBM WatsonX AI models |
|
||||
| [IBM WatsonxAI](https://www.ibm.com/watsonx) | `ibmwatsonxai` | IBM WatsonxAI specific integration |
|
||||
| [Custom REST](https://) | `customrest` | Any REST API that follows the OpenAI chat completion format |
|
||||
|
||||
## Other Tool Integrations
|
||||
|
||||
| Tool | Integration Type | Description |
|
||||
|------|-----------------|-------------|
|
||||
| [Claude Desktop](https://claude.ai/) | MCP Server | k8sgpt MCP server integrates with Claude Desktop for AI-assisted cluster analysis |
|
||||
| [Docker](https://www.docker.com/) | Container | Container image available on GitHub Container Registry |
|
||||
| [Minikube](https://minikube.sigs.k8s.io/) | Development | Works with Minikube clusters for development and testing |
|
||||
| [Kubeblocks](https://kubeblocks.io/) | Database Analysis | Analyzer support for KubeBlocks-managed databases |
|
||||
| [OpenShift](https://www.openshift.com/) | Platform | Analysis support for OpenShift-specific resources (CatalogSource, ClusterCatalog, etc.) |
|
||||
| [FluxCD](https://fluxcd.io/) | GitOps | Compatible with GitOps workflows using FluxCD |
|
||||
| [ArgoCD](https://argoproj.github.io/cd/) | GitOps | Compatible with GitOps workflows using ArgoCD |
|
||||
|
||||
## Remote Caching
|
||||
|
||||
k8sgpt supports remote caching of analysis results:
|
||||
|
||||
| Provider | Type | Description |
|
||||
|----------|------|-------------|
|
||||
| AWS S3 | Object Storage | Store analysis cache in AWS S3 buckets |
|
||||
| Azure Blob | Object Storage | Store analysis cache in Azure Blob Storage |
|
||||
| Google Cloud Storage | Object Storage | Store analysis cache in GCS buckets |
|
||||
|
||||
## How to Integrate
|
||||
|
||||
For custom analyzer integrations, see the [Custom Analyzers documentation](https://docs.k8sgpt.ai/tutorials/custom-analyzers/) and the [custom analyzer schema](https://github.com/k8sgpt-ai/schemas/blob/main/protobuf/schema/v1/custom_analyzer.proto).
|
||||
|
||||
For MCP server integration, see [MCP.md](MCP.md).
|
||||
@@ -0,0 +1,52 @@
|
||||
# Maintainers
|
||||
|
||||
This file lists all current maintainers of k8sgpt and their areas of responsibility.
|
||||
|
||||
## Maintainer Roles
|
||||
|
||||
- **Maintainer**: Has write access to the repository. Can review and merge PRs, triage issues, and manage releases.
|
||||
- **Approver**: Can review PRs but does not have merge permissions. Actively contributes and helps guide project direction.
|
||||
|
||||
## Current Maintainers
|
||||
|
||||
| Name | Affiliation | Domain of Responsibility | Contact |
|
||||
|------|-------------|--------------------------|---------|
|
||||
| AlexsJones | AWS | Project lead, core analyzers, architecture | @AlexsJones (GitHub), contact@k8sgpt.ai |
|
||||
| thschue | Independent | CLI, core logic, releases | @thschue (GitHub) |
|
||||
| matthisholleville | Agicap | Analyzers, integrations | @matthisholleville (GitHub) |
|
||||
| AnaisUrlichs | Independent | Documentation, community | @AnaisUrlichs (GitHub) |
|
||||
| bradmccoydev | @basiqio | CNCF community, governance | @bradmccoydev (GitHub) |
|
||||
| rakshitgondwal | Independent | Analyzers, testing | @rakshitgondwal (GitHub) |
|
||||
| roberthstrand | Independent | Community, outreach | @roberthstrand (GitHub) |
|
||||
|
||||
## Emeritus Maintainers
|
||||
|
||||
Maintainers who have stepped back from active roles:
|
||||
|
||||
| Name | Period | Reason |
|
||||
|------|--------|--------|
|
||||
| _(None yet)_ | | |
|
||||
|
||||
## Adding New Maintainers
|
||||
|
||||
To become a maintainer:
|
||||
1. Make significant, sustained contributions to the project (code, docs, community)
|
||||
2. Be nominated by an existing maintainer
|
||||
3. Receive approval from a majority of current maintainers
|
||||
4. Be added to this list and granted write access
|
||||
|
||||
## Maintainer Responsibilities
|
||||
|
||||
- Review and respond to issues and PRs in a timely manner
|
||||
- Maintain and improve analyzers
|
||||
- Participate in community discussions
|
||||
- Help with release management
|
||||
- Uphold the CNCF Code of Conduct
|
||||
- Contribute to project governance decisions
|
||||
|
||||
## Contact
|
||||
|
||||
For maintainer-related inquiries, reach out via:
|
||||
- GitHub: [k8sgpt-ai organization](https://github.com/k8sgpt-ai)
|
||||
- Slack: [#k8sgpt](https://join.slack.com/t/k8sgpt/shared_invite/zt-332vhyaxv-bfjJwHZLXWVCB3QaXafEYQ)
|
||||
- Email: contact@k8sgpt.ai
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
# Release Process
|
||||
|
||||
This document describes how k8sgpt releases are managed.
|
||||
|
||||
## Release Automation
|
||||
|
||||
k8sgpt uses automated release tooling:
|
||||
|
||||
- **[release-please](https://github.com/googleapis/release-please)** - Tracks changes and manages version bumping
|
||||
- **[GoReleaser](https://goreleaser.com/)** - Builds binaries, containers, and publishes releases
|
||||
|
||||
## Release Workflow
|
||||
|
||||
1. **Change Tracking**: Commits are tagged with conventional commit types (`feat:`, `fix:`, `chore:`, etc.)
|
||||
2. **Release PR**: release-please automatically creates a PR that tracks all changes and bumps the version
|
||||
3. **Merge to Main**: When the release PR is merged, the release workflow triggers
|
||||
4. **Build & Publish**: GoReleaser builds binaries for all platforms, creates container images, and publishes the release
|
||||
|
||||
### CI Pipeline
|
||||
|
||||
The release is managed by [`.github/workflows/release.yaml`](.github/workflows/release.yaml):
|
||||
|
||||
1. **Step 1 - release-please**: Analyzes commit history and creates a release PR with changelog
|
||||
2. **Step 2 - goreleaser**: When a new release is created, builds and publishes:
|
||||
- Binaries for Linux (amd64, arm64, 386), macOS (amd64, arm64), Windows (amd64, arm64)
|
||||
- Container images (ghcr.io/k8sgpt-ai/k8sgpt)
|
||||
- Helm chart updates
|
||||
- Homebrew tap updates
|
||||
- RPM, DEB, and APK packages
|
||||
|
||||
## Release Cadence
|
||||
|
||||
k8sgpt aims for **monthly releases**. Minor and patch releases happen as needed for bug fixes and security updates.
|
||||
|
||||
## Versioning
|
||||
|
||||
k8sgpt follows [Semantic Versioning](https://semver.org/): `MAJOR.MINOR.PATCH`
|
||||
|
||||
- **MAJOR**: Incompatible API changes
|
||||
- **MINOR**: New features, backward compatible
|
||||
- **PATCH**: Bug fixes, backward compatible
|
||||
|
||||
## Publishing Artifacts
|
||||
|
||||
Each release publishes:
|
||||
- [GitHub Releases](https://github.com/k8sgpt-ai/k8sgpt/releases) with changelog
|
||||
- Binaries via GitHub Releases
|
||||
- Container images on [ghcr.io/k8sgpt-ai/k8sgpt](https://ghcr.io/k8sgpt-ai/k8sgpt)
|
||||
- Helm chart via [k8sgpt-ai/charts](https://github.com/k8sgpt-ai/charts)
|
||||
- Homebrew formula via [k8sgpt-ai/homebrew-k8sgpt](https://github.com/k8sgpt-ai/homebrew-k8sgpt)
|
||||
- Krew plugin via [krew registry](https://github.com/k8sgpt-ai/k8sgpt/blob/main/.krew.yaml)
|
||||
- Package repositories (RPM, DEB, APK)
|
||||
|
||||
## Release Configuration
|
||||
|
||||
- [release-please-config.json](release-please-config.json) - Configures release-please behavior
|
||||
- [release-please-manifest.json](release-please-manifest.json) - Tracks current version
|
||||
- [.goreleaser.yaml](.goreleaser.yaml) - Configures GoReleaser build and publish
|
||||
|
||||
## Manual Release
|
||||
|
||||
While releases are automated, a manual release can be triggered via:
|
||||
```bash
|
||||
# Trigger the release workflow manually
|
||||
gh workflow run release.yaml -R k8sgpt-ai/k8sgpt
|
||||
```
|
||||
|
||||
## Contributing to Releases
|
||||
|
||||
Contributors do not need to manage releases. Just follow conventional commits and the release automation will handle the rest:
|
||||
- `feat:` - Will bump MINOR version
|
||||
- `fix:` - Will bump PATCH version
|
||||
- `chore:`, `docs:`, `refactor:` - Will bump PATCH version
|
||||
- `BREAKING CHANGE:` in commit body - Will bump MAJOR version
|
||||
+79
@@ -0,0 +1,79 @@
|
||||
# k8sgpt Roadmap
|
||||
|
||||
This document outlines the strategic direction and roadmap for k8sgpt. The roadmap is updated regularly based on community feedback and project needs.
|
||||
|
||||
## Project Vision
|
||||
|
||||
k8sgpt aims to give Kubernetes superpowers to everyone by providing AI-powered cluster analysis that is accessible to users of all skill levels. We believe every Kubernetes practitioner should have access to SRE-grade diagnostics, regardless of their experience.
|
||||
|
||||
## Current Focus Areas
|
||||
|
||||
### 1. Multi-Provider AI Backend Support
|
||||
- Expand support for diverse LLM providers beyond OpenAI
|
||||
- Support for local/offline models (Ollama, LocalAI) as first-class citizens
|
||||
- Improved model selection and fallback mechanisms
|
||||
- Support for custom REST backends
|
||||
|
||||
### 2. Analyzer Expansion
|
||||
- Add analyzers for emerging Kubernetes features
|
||||
- Improve existing analyzer accuracy
|
||||
- Custom analyzer framework improvements
|
||||
- Integration with OPA/Gatekeeper for policy analysis
|
||||
|
||||
### 3. Observability & Integration
|
||||
- Deeper Prometheus and OpenTelemetry integration
|
||||
- Grafana dashboard support
|
||||
- Slack, Discord, and Teams integrations
|
||||
- Webhook-based alerting
|
||||
|
||||
### 4. Performance & Scalability
|
||||
- Optimize analysis speed for large clusters
|
||||
- Improve caching mechanisms
|
||||
- Reduce memory footprint
|
||||
- Support for multi-cluster analysis
|
||||
|
||||
### 5. Security
|
||||
- Enhanced data anonymization during AI queries
|
||||
- Improved security analyzers
|
||||
- Compliance reporting features
|
||||
- Secret detection and redaction
|
||||
|
||||
## Planned Initiatives
|
||||
|
||||
### Near Term (Next 3-6 months)
|
||||
- [ ] Kubernetes 1.30+ feature support
|
||||
- [ ] Improved MCP server capabilities
|
||||
- [ ] Enhanced serve mode with metrics
|
||||
- [ ] Better error handling and diagnostics
|
||||
- [ ] Community analyzer marketplace
|
||||
|
||||
### Medium Term (6-12 months)
|
||||
- [ ] Multi-cluster analysis
|
||||
- [ ] Advanced anomaly detection
|
||||
- [ ] Historical trend analysis
|
||||
- [ ] Custom dashboard generation
|
||||
- [ ] Plugin ecosystem for third-party analyzers
|
||||
|
||||
### Long Term (12+ months)
|
||||
- [ ] Self-healing recommendations with automated remediation
|
||||
- [ ] Cross-cluster best practice benchmarking
|
||||
- [ ] AI model fine-tuning for Kubernetes diagnostics
|
||||
- [ ] Enterprise-grade access control and auditing
|
||||
|
||||
## How to Contribute
|
||||
|
||||
The roadmap is community-driven. To suggest new items:
|
||||
1. Open a GitHub issue with the `enhancement` label
|
||||
2. Discuss your idea in the [#k8sgpt Slack channel](https://join.slack.com/t/k8sgpt/shared_invite/zt-332vhyaxv-bfjJwHZLXWVCB3QaXafEYQ)
|
||||
3. Submit a PR implementing the feature
|
||||
|
||||
## Previous Roadmaps
|
||||
|
||||
- _(Initial roadmap created 2026-04-24)_
|
||||
|
||||
## Feedback
|
||||
|
||||
We welcome feedback on this roadmap. Please share your thoughts via:
|
||||
- GitHub Issues
|
||||
- Slack: [#k8sgpt](https://join.slack.com/t/k8sgpt/shared_invite/zt-332vhyaxv-bfjJwHZLXWVCB3QaXafEYQ)
|
||||
- GitHub Discussions
|
||||
@@ -0,0 +1,185 @@
|
||||
# k8sgpt Self-assessment
|
||||
|
||||
## Metadata
|
||||
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| Assessment Stage | Incomplete |
|
||||
| Software | https://github.com/k8sgpt-ai/k8sgpt |
|
||||
| Security Provider | No |
|
||||
| Languages | Go |
|
||||
| SBOM | Generated via Syft in release workflow (https://github.com/k8sgpt-ai/k8sgpt/blob/main/.github/workflows/release.yaml) |
|
||||
|
||||
### Security Links
|
||||
|
||||
| Doc | URL |
|
||||
|-----|-----|
|
||||
| Security Policy | https://github.com/k8sgpt-ai/k8sgpt/blob/main/SECURITY.md |
|
||||
| Code of Conduct | https://github.com/k8sgpt-ai/k8sgpt/blob/main/CODE_OF_CONDUCT.md |
|
||||
| OpenSSF Best Practices | https://bestpractices.coreinfrastructure.org/projects/7272 |
|
||||
| Contributing Guide | https://github.com/k8sgpt-ai/k8sgpt/blob/main/CONTRIBUTING.md |
|
||||
| Documentation | https://docs.k8sgpt.ai |
|
||||
|
||||
## Overview
|
||||
|
||||
k8sgpt is a tool for scanning Kubernetes clusters, diagnosing, and triaging issues in simple English. It has SRE experience codified into analyzers and helps pull out the most relevant information, enriching it with AI from various LLM providers.
|
||||
|
||||
### Background
|
||||
|
||||
k8sgpt operates by connecting to a Kubernetes cluster, running a suite of analyzers that check for common issues (pod failures, misconfigurations, resource limits, etc.), and using AI to explain findings in plain language. It is designed as a CLI tool and as a Kubernetes operator for continuous monitoring.
|
||||
|
||||
### Actors
|
||||
|
||||
1. **k8sgpt CLI** - The command-line tool that connects to a Kubernetes cluster via kubeconfig, runs analyzers, and displays results.
|
||||
2. **k8sgpt Operator** - A Kubernetes controller that continuously monitors the cluster and reports issues via alerts.
|
||||
3. **AI Backend** - External LLM provider (OpenAI, Azure, Cohere, Ollama, Amazon Bedrock, etc.) that provides analysis explanations. The operator does not communicate with external APIs.
|
||||
4. **Kubernetes Cluster** - The target cluster being analyzed. k8sgpt reads cluster state via the Kubernetes API.
|
||||
5. **Custom Analyzer** - Optional external HTTP service that can be called for custom analysis (via the custom analyzer framework).
|
||||
|
||||
### Actions
|
||||
|
||||
1. **Connection**: k8sgpt authenticates to the Kubernetes cluster using the user's kubeconfig (in-cluster or local).
|
||||
2. **Analysis**: Analyzers query the Kubernetes API for specific resource states and check for known issue patterns.
|
||||
3. **Filtering**: Results are filtered based on user-configured filters to reduce noise.
|
||||
4. **AI Explanation** (optional): When `--explain` is used, analysis results are sent to an AI backend for natural language explanation. Sensitive data is masked before being sent.
|
||||
5. **Output**: Results are displayed in the CLI, exported to JSON, or sent via integrations (Slack, Prometheus, etc.).
|
||||
6. **Operator Mode**: The k8sgpt operator runs continuously, performing periodic scans and alerting on issues.
|
||||
|
||||
### Goals
|
||||
|
||||
- Provide accessible Kubernetes diagnostics for users of all skill levels
|
||||
- Codify SRE expertise into automated analyzers
|
||||
- Support multiple AI backends for flexibility and vendor neutrality
|
||||
- Enable continuous cluster monitoring via the operator
|
||||
- Maintain data privacy through anonymization of sensitive cluster data before sending to AI backends
|
||||
|
||||
### Non-goals
|
||||
|
||||
- k8sgpt does not modify or remediate cluster state (it is read-only)
|
||||
- k8sgpt does not replace comprehensive security scanning tools (it focuses on Kubernetes operational issues)
|
||||
- k8sgpt does not store cluster data persistently (except optional remote caching)
|
||||
- k8sgpt does not provide its own AI model (it consumes external AI APIs)
|
||||
|
||||
## Self-assessment use
|
||||
|
||||
This self-assessment is created by the k8sgpt team to perform an internal analysis of the project's security. It is not intended to provide a security audit of k8sgpt, or function as an independent assessment or attestation of k8sgpt's security health.
|
||||
|
||||
This document serves to provide k8sgpt users with an initial understanding of k8sgpt's security, where to find existing security documentation, k8sgpt plans for security, and general overview of k8sgpt security practices, both for development of k8sgpt as well as security of k8sgpt.
|
||||
|
||||
This document provides the CNCF TAG-Security with an initial understanding of k8sgpt to assist in a joint-assessment, necessary for projects under incubation. Taken together, this document and the joint-assessment serve as a cornerstone for if and when k8sgpt seeks graduation and is preparing for a security audit.
|
||||
|
||||
## Security Functions and Features
|
||||
|
||||
### Critical
|
||||
|
||||
| Component | Description |
|
||||
|-----------|-------------|
|
||||
| **Data Anonymization** | k8sgpt masks sensitive Kubernetes resource data (names, labels, etc.) before sending to AI backends. This prevents accidental exposure of sensitive cluster state. |
|
||||
| **Read-only API Access** | k8sgpt only reads from the Kubernetes API. It never modifies cluster state, reducing the attack surface. |
|
||||
| **Secure Config Storage** | AI API keys are stored locally in `$XDG_CONFIG_HOME/k8sgpt/k8sgpt.yaml`. Users are responsible for securing this file. |
|
||||
| **TLS for API Communication** | All communication with AI backends uses HTTPS/TLS. |
|
||||
|
||||
### Security Relevant
|
||||
|
||||
| Component | Description |
|
||||
|-----------|-------------|
|
||||
| **AI Backend Configuration** | Users can configure which AI backend to use. Local options (Ollama, LocalAI) keep data within the user's network. |
|
||||
| **Anonymization Settings** | Users can enable/disable anonymization. When enabled, sensitive data is masked before AI queries. |
|
||||
| **Filter Configuration** | Users can configure which analyzers and filters are active, controlling what data is processed. |
|
||||
| **Remote Caching** | Optional S3/Azure/GCS caching. Users must secure their storage credentials. |
|
||||
| **Custom Headers** | Users can add custom headers to AI requests for additional authentication (e.g., API keys). |
|
||||
| **Container Image Signing** | Release workflow generates SBOM via Syft for supply chain transparency. |
|
||||
|
||||
## Project Compliance
|
||||
|
||||
k8sgpt currently complies with:
|
||||
- **CNCF Code of Conduct** - All contributors must follow the CNCF CoC
|
||||
- **OpenSSF Best Practices** - Project maintains an OpenSSF Best Practices badge
|
||||
- **Apache 2.0 License** - Clear, permissive open source license
|
||||
- **DCO (Developer Certificate of Origin)** - All commits must be signed off
|
||||
|
||||
## Secure Development Practices
|
||||
|
||||
### Development Pipeline
|
||||
|
||||
- **Go Modules** - All dependencies are managed via Go modules with strict version pinning
|
||||
- **Renovate** - Automated dependency updates with auto-merge for non-major versions
|
||||
- **CI Pipeline** - Every PR triggers:
|
||||
- Go compilation and build
|
||||
- Unit and integration tests
|
||||
- Go linter (golangci-lint)
|
||||
- Semantic PR validation
|
||||
- Container image build
|
||||
- **Code Review** - All changes require at least one maintainer review (enforced via CODEOWNERS)
|
||||
- **DCO Enforcement** - All commits must be signed off via DCO check
|
||||
- **Branch Protection** - Main branch requires PR review and passing CI
|
||||
- **Conventional Commits** - All commits follow conventional commit format for release automation
|
||||
- **Release Process** - Automated releases via release-please and GoReleaser
|
||||
|
||||
### Communication Channels
|
||||
|
||||
- **Internal**: GitHub Issues, GitHub Discussions, Slack (#k8sgpt)
|
||||
- **Inbound**: GitHub Issues (bug reports, feature requests), Slack (#k8sgpt), Email (contact@k8sgpt.ai for security)
|
||||
- **Outbound**: GitHub Releases, Slack announcements, CNCF mailing list, blog posts
|
||||
|
||||
### Ecosystem
|
||||
|
||||
k8sgpt is deeply integrated into the Kubernetes ecosystem:
|
||||
- Native Kubernetes API interaction via client-go
|
||||
- Helm chart distribution via k8sgpt-ai/charts
|
||||
- Krew plugin distribution
|
||||
- Homebrew tap for easy installation
|
||||
- Integration with Prometheus and Alertmanager for monitoring
|
||||
- Compatible with GitOps tools (ArgoCD, FluxCD)
|
||||
- MCP server integration for AI assistant workflows
|
||||
|
||||
## Security Issue Resolution
|
||||
|
||||
### Responsible Disclosure Process
|
||||
|
||||
Users who discover security vulnerabilities in k8sgpt should:
|
||||
|
||||
1. **Report via Email**: Send details to contact@k8sgpt.ai
|
||||
2. **Report via Slack**: Contact a maintainer in the #k8sgpt Slack channel
|
||||
3. **GitHub Security Advisories**: Use the "Report a vulnerability" button on the GitHub repository
|
||||
|
||||
### Vulnerability Response Process
|
||||
|
||||
1. **Acknowledgment**: Maintainers acknowledge receipt within 48 hours
|
||||
2. **Assessment**: The vulnerability is assessed for severity and impact
|
||||
3. **Fix**: A fix is developed and tested
|
||||
4. **Disclosure**: The vulnerability is disclosed via GitHub Security Advisories and a new release is published
|
||||
5. **Communication**: Users are notified via GitHub Releases and Slack
|
||||
|
||||
### Incident Response
|
||||
|
||||
1. **Triage**: Security reports are triaged by the maintainer team
|
||||
2. **Confirmation**: The reported issue is confirmed and severity is assessed
|
||||
3. **Notification**: Affected users are notified via GitHub and Slack
|
||||
4. **Patching**: A fix is developed and published in a patch release
|
||||
5. **Post-mortem**: If applicable, a post-mortem is shared with the community
|
||||
|
||||
### Known Security Considerations
|
||||
|
||||
- **AI Backend Data Exposure**: While anonymization is the default, users should be aware that analysis results (including Kubernetes resource names) may be sent to external AI providers when using `--explain`. Users concerned about data privacy should use local models (Ollama, LocalAI) or review the anonymization settings.
|
||||
- **Config File Security**: AI API keys are stored in plaintext in the local config file. Users should secure this file and restrict access.
|
||||
- **Custom Analyzer Security**: Custom analyzers run as separate HTTP services. Users should ensure these services are properly secured and only accessible from trusted networks.
|
||||
|
||||
## Appendix
|
||||
|
||||
### OpenSSF Best Practices
|
||||
|
||||
k8sgpt maintains an [OpenSSF Best Practices badge](https://bestpractices.coreinfrastructure.org/projects/7272). The project actively addresses non-passing criteria and works toward a 100% score.
|
||||
|
||||
### Related Projects
|
||||
|
||||
- **Prometheus** - Prometheus provides metrics collection; k8sgpt provides diagnostic analysis
|
||||
- **kube-linter** - kube-linter focuses on static analysis of Kubernetes manifests; k8sgpt provides runtime analysis
|
||||
- **Sonobuoy** - Sonobuoy provides Kubernetes cluster conformance testing; k8sgpt provides operational issue detection
|
||||
- **Kubescape** - Kubescape focuses on security posture assessment; k8sgpt focuses on operational diagnostics with AI-powered explanations
|
||||
|
||||
### Case Studies
|
||||
|
||||
1. **Day-to-day cluster troubleshooting**: SREs use k8sgpt to quickly identify and explain common Kubernetes issues (crashlooping pods, failed deployments, resource limits) without deep domain knowledge.
|
||||
2. **On-call support**: Junior team members use k8sgpt's AI-powered explanations to understand and resolve cluster issues during on-call rotations.
|
||||
3. **Continuous monitoring**: Teams deploy the k8sgpt operator to continuously monitor cluster health and alert on issues via Prometheus/Alertmanager integration.
|
||||
Reference in New Issue
Block a user