docs: add Kubernetes (Helm) deployment guide#100
Conversation
…nd troubleshooting guide
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly expands the PipesHub documentation by introducing a complete guide for deploying the application on Kubernetes using Helm. The new content provides users with detailed instructions and best practices for setting up, configuring, and maintaining PipesHub in a containerized, production-ready environment, enhancing the overall deployment flexibility and user experience. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a comprehensive set of documentation for deploying PipesHub on Kubernetes using Helm. The new guides cover an overview, installation, configuration, Ingress setup, and troubleshooting, which is a great addition. My review includes a few suggestions to improve the documentation's clarity and to promote Kubernetes best practices in the examples, such as using specific image tags instead of 'latest' and using a more portable Ingress pathType.
| image: | ||
| repository: pipeshubai/pipeshub-ai | ||
| tag: latest | ||
| pullPolicy: Always |
There was a problem hiding this comment.
Using the latest image tag is discouraged in production environments. It can lead to unexpected behavior because the image content can change without the tag changing, and it makes tracking which version is running and performing rollbacks difficult. It's a best practice to use immutable tags, such as a specific version (v1.2.3) or the git commit SHA. When using specific tags, pullPolicy: IfNotPresent is also recommended.
image:
repository: pipeshubai/pipeshub-ai
tag: "<specific-version>"
pullPolicy: IfNotPresent
|
|
||
| - **3000**: frontend | ||
| - **8088**: connector | ||
| - **8091**: main backend (indexing backend uses the same pod, different port naming) |
There was a problem hiding this comment.
The description for port 8091 is a bit confusing. It says "main backend (indexing backend uses the same pod, different port naming)", but then port 8081 is listed separately for "indexing". To improve clarity, I suggest removing the parenthetical note, as the separation of ports in the list is already clear.
- **8091**: main backend
| hosts: | ||
| - host: pipeshub.example.com | ||
| paths: | ||
| - path: / | ||
| pathType: ImplementationSpecific | ||
| port: 3000 | ||
| serviceName: pipeshub-pipeshub-ai | ||
| - host: pipeshub-connector.example.com | ||
| paths: | ||
| - path: / | ||
| pathType: ImplementationSpecific | ||
| port: 8088 | ||
| serviceName: pipeshub-pipeshub-ai |
There was a problem hiding this comment.
For pathType, Prefix is generally a better choice than ImplementationSpecific when the path is /. ImplementationSpecific delegates the interpretation to the Ingress controller, which can lead to inconsistent behavior across different Kubernetes environments. Using Prefix provides a clear, portable definition for path matching. I recommend using Prefix for both host path definitions to ensure predictability.
hosts:
- host: pipeshub.example.com
paths:
- path: /
pathType: Prefix
port: 3000
serviceName: pipeshub-pipeshub-ai
- host: pipeshub-connector.example.com
paths:
- path: /
pathType: Prefix
port: 8088
serviceName: pipeshub-pipeshub-ai
| - Follow the Helm install guide in [`deployment/kubernetes/helm`](./helm). | ||
| - Configure values (secrets, persistence, URLs) in [`deployment/kubernetes/configuration`](./configuration). | ||
| - If you want HTTPS + hostnames, see [`deployment/kubernetes/ingress`](./ingress). |
There was a problem hiding this comment.
The link text in this list is the file path, which is redundant and not very user-friendly. For better readability, consider using more descriptive link text. Additionally, the links are missing the .mdx file extension, which is used in other parts of the documentation. Adding it would improve consistency.
- Follow the [Helm install guide](./helm.mdx).
- Configure values (secrets, persistence, URLs) in the [configuration guide](./configuration.mdx).
- If you want HTTPS + hostnames, see the [Ingress and TLS guide](./ingress.mdx).
…ying service exposure and Ingress configuration
1 participant
Summary
docs.pipeshub.com.Scope
deployment/kubernetes/overview.mdxdeployment/kubernetes/helm.mdxdeployment/kubernetes/configuration.mdxdeployment/kubernetes/ingress.mdxdeployment/kubernetes/troubleshooting.mdxdeployment/overview.mdxdocs.jsonintroduction.mdx(Deployment section now mentions Kubernetes/Helm)deployment/helmis a symlink to the Helm chart source for reference during docs development.Test / verification
mintlify devand verified navigation + linksdocs.jsonScreenshots