2022-08-24 16:26:41 +03:00
|
|
|
|
---
|
|
|
|
|
date: "2020-03-19T19:27:00+02:00"
|
2023-05-25 07:32:39 +03:00
|
|
|
|
title: "在 Kubernetes 中安装 Gitea"
|
2022-08-24 16:26:41 +03:00
|
|
|
|
slug: "install-on-kubernetes"
|
2023-04-04 16:47:31 +03:00
|
|
|
|
weight: 80
|
2022-08-24 16:26:41 +03:00
|
|
|
|
toc: false
|
|
|
|
|
draft: false
|
Refactor docs (#23752)
This was intended to be a small followup for
https://github.com/go-gitea/gitea/pull/23712, but...here we are.
1. Our docs currently use `slug` as the entire URL, which makes
refactoring tricky (see https://github.com/go-gitea/gitea/pull/23712).
Instead, this PR attempts to make future refactoring easier by using
slugs as an extension of the section. (Hugo terminology)
- What the above boils down to is this PR attempts to use directory
organization as URL management. e.g. `usage/comparison.en-us.md` ->
`en-us/usage/comparison/`, `usage/packages/overview.en-us.md` ->
`en-us/usage/packages/overview/`
- Technically we could even remove `slug`, as Hugo defaults to using
filename, however at least with this PR it means `slug` only needs to be
the name for the **current file** rather than an entire URL
2. This PR adds appropriate aliases (redirects) for pages, so anything
on the internet that links to our docs should hopefully not break.
3. A minor nit I've had for a while, renaming `seek-help` to `support`.
It's a minor thing, but `seek-help` has a strange connotation to it.
4. The commits are split such that you can review the first which is the
"actual" change, and the second is added redirects so that the first
doesn't break links elsewhere.
---------
Signed-off-by: jolheiser <john.olheiser@gmail.com>
2023-04-28 06:33:41 +03:00
|
|
|
|
aliases:
|
|
|
|
|
- /zh-cn/install-on-kubernetes
|
2022-08-24 16:26:41 +03:00
|
|
|
|
menu:
|
|
|
|
|
sidebar:
|
|
|
|
|
parent: "installation"
|
2023-05-25 07:32:39 +03:00
|
|
|
|
name: "在 Kubernetes 中安装 Gitea"
|
2023-04-04 16:47:31 +03:00
|
|
|
|
weight: 80
|
2022-08-24 16:26:41 +03:00
|
|
|
|
identifier: "install-on-kubernetes"
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# 使用 Helm 在 Kubernetes 云原生环境中安装 Gitea
|
|
|
|
|
|
|
|
|
|
Gitea 已经提供了便于在 Kubernetes 云原生环境中安装所需的 Helm Chart
|
|
|
|
|
|
|
|
|
|
默认安装指令为:
|
|
|
|
|
|
|
|
|
|
```bash
|
2023-06-21 06:11:17 +03:00
|
|
|
|
helm repo add gitea https://dl.gitea.com/charts
|
2022-08-24 16:26:41 +03:00
|
|
|
|
helm repo update
|
|
|
|
|
helm install gitea gitea/gitea
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
如果采用默认安装指令,Helm 会部署单实例的 Gitea, PostgreSQL, Memcached。若您想实现自定义安装(包括配置 Gitea 集群、NGINX Ingress、MySQL、MariaDB、持久存储等),请前往阅读:[Gitea Helm Chart](https://gitea.com/gitea/helm-chart/)
|
|
|
|
|
|
|
|
|
|
您也可以通过 `helm show` 命令导出 `README.md` 和配置文件 `values.yaml` 进行学习和编辑,例如:
|
|
|
|
|
|
|
|
|
|
```bash
|
2022-08-31 19:47:34 +03:00
|
|
|
|
helm show values gitea/gitea > values.yaml
|
|
|
|
|
helm show readme gitea/gitea > README.md
|
2022-08-24 16:26:41 +03:00
|
|
|
|
|
|
|
|
|
# 使用自定义的配置文件 values.yaml
|
|
|
|
|
helm install gitea -f values.yaml gitea/gitea
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## 运行状况检查接口
|
|
|
|
|
|
|
|
|
|
Gitea 附带了一个运行状况检查接口 `/api/healthz`,你可以像这样在 Kubernetes 中配置它:
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
livenessProbe:
|
|
|
|
|
httpGet:
|
|
|
|
|
path: /api/healthz
|
|
|
|
|
port: http
|
|
|
|
|
initialDelaySeconds: 200
|
|
|
|
|
timeoutSeconds: 5
|
|
|
|
|
periodSeconds: 10
|
|
|
|
|
successThreshold: 1
|
|
|
|
|
failureThreshold: 10
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
成功的运行状况检查响应代码为 HTTP `200`,下面是示例:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
HTTP/1.1 200 OK
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
"status": "pass",
|
|
|
|
|
"description": "Gitea: Git with a cup of tea",
|
|
|
|
|
"checks": {
|
|
|
|
|
"cache:ping": [
|
|
|
|
|
{
|
|
|
|
|
"status": "pass",
|
|
|
|
|
"time": "2022-02-19T09:16:08Z"
|
|
|
|
|
}
|
|
|
|
|
],
|
|
|
|
|
"database:ping": [
|
|
|
|
|
{
|
|
|
|
|
"status": "pass",
|
|
|
|
|
"time": "2022-02-19T09:16:08Z"
|
|
|
|
|
}
|
|
|
|
|
]
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
有关更多信息,请参考 Kubernetes 文档 [配置存活、就绪和启动探测器](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
|