mirror of
https://github.com/kubesphere/website.git
synced 2025-12-26 00:12:48 +00:00
pull upstream
This commit is contained in:
liuboaibc
commit
8bc63b9bf6
|
|
@ -126,83 +126,99 @@ languageName = "简体中文"
|
|||
|
||||
[[languages.zh.menu.main]]
|
||||
weight = 2
|
||||
name = "Scenario"
|
||||
name = "应用场景"
|
||||
hasChildren = true
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
parent = "Scenario"
|
||||
name = "DevOps"
|
||||
URL = "devOps"
|
||||
parent = "应用场景"
|
||||
name = "拥抱一站式 DevOps 工作流"
|
||||
URL = "devops"
|
||||
weight = 2
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
parent = "Scenario"
|
||||
name = "Service Mesh"
|
||||
parent = "应用场景"
|
||||
name = "在 Kubernetes 运行微服务"
|
||||
URL = "service-mesh"
|
||||
weight = 4
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
parent = "Scenario"
|
||||
name = "Observability"
|
||||
parent = "应用场景"
|
||||
name = "构建丰富的云原生可观察性"
|
||||
URL = "observability"
|
||||
weight = 8
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
weight = 3
|
||||
name = "Resources"
|
||||
name = "资源"
|
||||
hasChildren = true
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
parent = "Resources"
|
||||
name = "Open Source Projects"
|
||||
parent = "资源"
|
||||
name = "开源项目"
|
||||
URL = "projects"
|
||||
weight = 1
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
parent = "Resources"
|
||||
name = "KubeCon & QCon"
|
||||
parent = "资源"
|
||||
name = "开源峰会"
|
||||
URL = "conferences"
|
||||
weight = 2
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
parent = "Resources"
|
||||
name = "Technology Blogs"
|
||||
parent = "资源"
|
||||
name = "技术博客"
|
||||
URL = "blogs"
|
||||
weight = 3
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
parent = "Resources"
|
||||
name = "Video Resources"
|
||||
parent = "资源"
|
||||
name = "视频资源"
|
||||
URL = "videos"
|
||||
weight = 4
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
weight = 4
|
||||
name = "Documentation"
|
||||
URL = "docs"
|
||||
name = "文档中心"
|
||||
URL = "https://kubesphere.com.cn/docs/zh-CN/"
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
weight = 5
|
||||
hasChildren = true
|
||||
name = "Community"
|
||||
name = "开源社区"
|
||||
[[languages.zh.menu.main]]
|
||||
parent = "Community"
|
||||
name = "Contribution"
|
||||
parent = "开源社区"
|
||||
name = "参与贡献"
|
||||
URL = "contribution"
|
||||
weight = 1
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
parent = "Community"
|
||||
name = "Case Studies"
|
||||
parent = "开源社区"
|
||||
name = "案例学习"
|
||||
URL = "case"
|
||||
weight = 2
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
parent = "Community"
|
||||
name = "Partner"
|
||||
parent = "开源社区"
|
||||
name = "合作伙伴"
|
||||
URL = "partner"
|
||||
weight = 3
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
parent = "开源社区"
|
||||
name = "版本计划"
|
||||
URL = "https://github.com/kubesphere/kubesphere/blob/master/docs/roadmap.md"
|
||||
weight = 4
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
parent = "开源社区"
|
||||
name = "中国站"
|
||||
URL = "https://kubesphere.com.cn/"
|
||||
weight = 5
|
||||
|
||||
[[languages.zh.menu.main]]
|
||||
weight = 6
|
||||
name = "用户论坛"
|
||||
URL = "https://kubesphere.com.cn/forum"
|
||||
|
||||
|
||||
[languages.tr]
|
||||
|
|
|
|||
|
|
@ -122,11 +122,11 @@ All resources in Porter are CRD, including VIP, BGPPeer and BGPConfig. Users who
|
|||
|
||||
The VIP traffic of user access will go to a node in the Kubernetes cluster under BGP. This is because the routes advertised by Porter are also nodes instead of Pod IP which is inaccessible externally. The path from a node to a pod is maintained by kube-proxy as below:
|
||||
|
||||
|
||||
|
||||
|
||||
The traffic will be sent to a pod randomly after the SNAT process. As Port will adjust routes based on the dynamic change of Service Endpoints to make sure a pod is available in a node for the next hop, we can change kube-proxy which is set by default. You can set ExternalTrafficPolicy=local in a Service and the result is shown as follows:
|
||||
The traffic will be sent to a pod randomly after the SNAT process. As Port will adjust routes based on the dynamic change of Service Endpoints to make sure a pod is available in a node for the next hop, we can change kube-proxy which is set by default. You can set **ExternalTrafficPolicy=local** in a Service and the result is shown as follows:
|
||||
|
||||
|
||||
|
||||
|
||||
There are two advantages in this method:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,249 @@
|
|||
---
|
||||
title: '使用 KubeSphere DevOps 搭建自动化测试系统'
|
||||
tag: 'KubeSphere,Kubernetes'
|
||||
createTime: '2020-04-29'
|
||||
author: 'Shaowen Chen'
|
||||
snapshot: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200428175258.png'
|
||||
---
|
||||
|
||||
## 测试分层
|
||||
|
||||
测试的目的是为了验证预期的功能，发现潜在的缺陷。测试增强了交付合格产品的信心，也给敏捷迭代带来了可能。可以说，测试决定了产品的开发进度。
|
||||
|
||||
网络模型有七层的 OSI 、四层的 TCP，而开发模式有 MTV、MVC、MVP、MVVM 等。高内聚、低耦合，划分职责、分模块、分层。然后结构化、标准化，技术逐步走向成熟。
|
||||
|
||||
测试也分为，UI 测试、API 测试、单元测试。测试并不是一项新技术，更多是产出与成本的一种平衡。
|
||||
|
||||
|
||||
|
||||
如上图，是一个测试金字塔。越往上，需要的成本越高，对环境要求越高，执行时间越长，维护越麻烦，但更贴近终端用户的场景。在 《Google软件测试之道》中，按照谷歌的经验，各层测试用例比例是 70：20：10，也就是 70% 的单元测试，20% 的 API 测试，10% 的 UI 测试。
|
||||
|
||||
本篇主要讲的是如何在 KubeSphere 平台上使用 **KubeSphere DevOps 系统** 运行自动化测试。
|
||||
|
||||
## 什么是 KubeSphere DevOps
|
||||
|
||||
KubeSphere 针对容器与 Kubernetes 的应用场景，基于 Jenkins 提供了一站式 DevOps 系统，包括丰富的 CI/CD 流水线构建与插件管理功能，还提供 Binary-to-Image（B2I）、Source-to-Image（S2I），为流水线、S2I、B2I 提供代码依赖缓存支持，以及代码质量管理与流水线日志等功能。
|
||||
|
||||
KubeSphere 内置的 DevOps 系统将应用的开发和自动发布与容器平台进行了很好的结合，还支持对接第三方的私有镜像仓库和代码仓库形成完善的私有场景下的 CI/CD，提供了端到端的用户体验。
|
||||
|
||||
但是，很少有用户知道，KubeSphere DevOps 还可以用来搭建自动化测试系统，为自动化的**单元测试、API 测试和 UI 测试**带来极大的便利性，提高测试人员的工作效率。
|
||||
|
||||
|
||||
|
||||
## 单元测试
|
||||
|
||||
单元测试的运行频率非常高，每次提交代码都应该触发一次。单元测试的依赖少，通常只需要一个容器运行环境即可。
|
||||
|
||||
下面是一个使用 golang:latest 跑单元测试的例子。
|
||||
|
||||
```
|
||||
pipeline {
|
||||
agent {
|
||||
node {
|
||||
label 'go'
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('testing') {
|
||||
steps {
|
||||
container('go') {
|
||||
sh '''
|
||||
git clone https://github.com/etcd-io/etcd.git
|
||||
cd etcd
|
||||
make test
|
||||
'''
|
||||
}
|
||||
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
执行日志：
|
||||
|
||||
|
||||
|
||||
针对其他语言、框架，单元测试通过安装一些包、Mock 相关服务，也能够便捷地运行在 Kubernetes 上。更多可以挖掘的是写单元测试的技巧，而不是运行时和单元测试方案。
|
||||
|
||||
## API 测试
|
||||
|
||||
如果团队的自动化测试刚起步，API 自动化测试是非常好的切入点。
|
||||
|
||||
单元测试主要由研发负责写。在快速迭代的过程中，有经验的研发也不会忘记写单元测试。重构、变更越快，测试不会成为负担，反而更重要。没有写单元测试，只能说其不被重视。推动一件不被执行者重视、管理者很难看到收益的事情是非常难的。
|
||||
|
||||
而 UI 自动化测试常常又被人工测试替代。同时，维护 UI 自动化测试成本较高，在快速迭代的过程中，不应该过多地进行 UI 自动化测试。
|
||||
|
||||
API 测试的优势在于，在前后端分离的架构下，API 相关的文档和资料相对完善，团队成员对 API 相对熟悉，有利于进行测试。
|
||||
|
||||
下面是一个使用 Postman 进行 API 自动化测试的例子：
|
||||
|
||||
```
|
||||
pipeline {
|
||||
agent {
|
||||
kubernetes {
|
||||
label 'apitest'
|
||||
yaml '''apiVersion: v1
|
||||
kind: Pod
|
||||
spec:
|
||||
containers:
|
||||
- name: newman
|
||||
image: postman/newman_alpine33
|
||||
command: [\'cat\']
|
||||
tty: true
|
||||
volumeMounts:
|
||||
- name: dockersock
|
||||
mountPath: /var/run/docker.sock
|
||||
- name: dockerbin
|
||||
mountPath: /usr/bin/docker
|
||||
volumes:
|
||||
- name: dockersock
|
||||
hostPath:
|
||||
path: /var/run/docker.sock
|
||||
- name: dockerbin
|
||||
hostPath:
|
||||
path: /usr/bin/docker
|
||||
'''
|
||||
defaultContainer 'newman'
|
||||
}
|
||||
}
|
||||
|
||||
parameters {
|
||||
string(name: 'HOST', defaultValue: '10.10.10.10', description: '')
|
||||
string(name: 'PORT', defaultValue: '8000', description: '')
|
||||
string(name: 'USERNAME', defaultValue: 'admin', description: '')
|
||||
string(name: 'PASSWORD', defaultValue: 'password', description: '')
|
||||
|
||||
}
|
||||
|
||||
stages {
|
||||
stage('testing') {
|
||||
steps {
|
||||
sh '''
|
||||
apk add --no-cache bash git openssh
|
||||
git clone https://yourdomain.com/ns/ks-api-test.git
|
||||
|
||||
cd ks-api-test
|
||||
|
||||
sed -i "s/__HOST__/$HOST/g" postman_environment.json
|
||||
sed -i "s/__PORT__/$PORT/g" postman_environment.json
|
||||
sed -i "s/__USERNAME__/$USERNAME/g" postman_environment.json
|
||||
sed -i "s/__PASSWORD__/$PASSWORD/g" postman_environment.json
|
||||
|
||||
npm install -g newman-reporter-htmlextra
|
||||
newman run iam/postman_collection.json -e postman_environment.json -r htmlextra
|
||||
'''
|
||||
}
|
||||
}
|
||||
}
|
||||
post {
|
||||
always {
|
||||
archiveArtifacts 'ks-api-test/newman/*'
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
执行后的归档：
|
||||
|
||||
|
||||
|
||||
下载归档的构件，解压后查看测试报告：
|
||||
|
||||
|
||||
|
||||
API 自动化测试的框架很容易实现，实现几点功能即可：
|
||||
|
||||
- 接口请求
|
||||
- 响应断言
|
||||
- 请求编排
|
||||
- 生成报告
|
||||
|
||||
但一定要根据团队的 API 测试、交付习惯选择合适的方案。可以自己开发，也可以使用现有的工具。上面选择的是 Postman + Newman 的方案，原因是团队普遍都使用 Postman 进行 API 测试。
|
||||
|
||||
剩下的就是如何组织大家进行测试，可以分别提交文件到一个共同的仓库，也可以使用付费版 Postman 共享数据集中测试。
|
||||
|
||||
## UI 测试
|
||||
|
||||
UI 自动化测试的成本高有几个方面：
|
||||
|
||||
- 测试用例难维护。前端样式变化、产品逻辑变化。
|
||||
- 很难提供稳定的运行环境。各种超时、脏数据会导致失败率很高。
|
||||
|
||||
这里的 UI 自动化测试，采用的是我熟悉的 Robotframework 框架，使用关键字进行自动化测试。
|
||||
|
||||
下面是一个使用 Robotframework 进行 UI 自动化测试的例子：
|
||||
|
||||
```
|
||||
pipeline {
|
||||
agent {
|
||||
kubernetes {
|
||||
label 'robotframework'
|
||||
yaml '''apiVersion: v1
|
||||
kind: Pod
|
||||
spec:
|
||||
containers:
|
||||
- name: robotframework
|
||||
image: shaowenchen/docker-robotframework:latest
|
||||
tty: true
|
||||
volumeMounts:
|
||||
- name: dockersock
|
||||
mountPath: /var/run/docker.sock
|
||||
- name: dockerbin
|
||||
mountPath: /usr/bin/docker
|
||||
volumes:
|
||||
- name: dockersock
|
||||
hostPath:
|
||||
path: /var/run/docker.sock
|
||||
- name: dockerbin
|
||||
hostPath:
|
||||
path: /usr/bin/docker
|
||||
'''
|
||||
defaultContainer 'robotframework'
|
||||
}
|
||||
}
|
||||
|
||||
parameters {
|
||||
string(name: 'HOST', defaultValue: '10.10.10.10', description: '')
|
||||
string(name: 'PORT', defaultValue: '8080', description: '')
|
||||
string(name: 'USERNAME', defaultValue: 'admin', description: '')
|
||||
string(name: 'PASSWORD', defaultValue: 'password', description: '')
|
||||
}
|
||||
|
||||
stages {
|
||||
stage('testing') {
|
||||
steps {
|
||||
sh '''
|
||||
curl -s -L https://raw.githubusercontent.com/shaowenchen/scripts/master/kubesphere/preinstall.sh | bash
|
||||
git clone https://yourdomain.com/ns/ks-ui-test.git
|
||||
|
||||
cd ks-ui-test
|
||||
|
||||
sed -i "s/__USERNAME__/$USERNAME/g" tests/common.robot
|
||||
sed -i "s/__PASSWORD__/$PASSWORD/g" tests/common.robot
|
||||
|
||||
echo "\nTestEnv http://$HOST:$PORT" >> tests/api.robot
|
||||
echo "\nTestEnv http://$HOST:$PORT" >> tests/devops.robot
|
||||
./start.sh'''
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
post {
|
||||
always {
|
||||
sh 'tar cvf report-$BUILD_NUMBER.tar ks-ui-test/tests/report'
|
||||
archiveArtifacts '*.tar'
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
执行日志：
|
||||
|
||||
|
||||
|
||||
下载归档的构件，解压后查看测试报告：
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,122 @@
|
|||
---
|
||||
title: '使用 KubeSphere 在 Kubernetes 安装 cert-manager 为网站启用 HTTPS'
|
||||
tag: 'KubeSphere,Kubernetes'
|
||||
createTime: '2020-04-29'
|
||||
author: 'Jeff Zhang'
|
||||
snapshot: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200428230558.png'
|
||||
---
|
||||
|
||||
|
||||
|
||||
## 什么是 cert-manager
|
||||
|
||||
cert-manager（`https://cert-manager.io/`）是 Kubernetes 原生的证书管理控制器。它可以帮助从各种来源颁发证书，例如 Let's Encrypt，HashiCorp Vault，Venafi，简单的签名密钥对或自签名。它将确保证书有效并且是最新的，并在证书到期前尝试在配置的时间续订证书。它大致基于 kube-lego 的原理，并从其他类似项目（例如 kube-cert-manager）中借鉴了一些智慧。
|
||||
|
||||
|
||||
|
||||
### 准备工作
|
||||
|
||||
1. 需要一个公网可访问的 IP，例如 `139.198.121.121`
|
||||
2. 需要一个域名，并且已经解析到到对应的IP，例如 ` A kubesphere.io 139.198.121.121`，我们将 `staging.kubesphere.io` 域名解析到了 `139.198.121.121`
|
||||
3. 在KubeSphere上已经运行网站对应的服务，例如本例中的`ks-console`
|
||||
|
||||
### 启用项目网关
|
||||
|
||||
登录 KubeSphere，进入任意一个企业空间下的项目中。
|
||||
|
||||
|
||||
|
||||
在 KubeSphere 中启用对应项目下的网关。
|
||||
|
||||
|
||||
|
||||
> 我们开启的是一个NodePort类型的网关，需要在集群外部使用 LoadBalancer 转发到网关的端口，将 `139.198.121.121` 绑定到 LoadBalancer 上，这样我们就可以通过公网IP直接访问我们的服务了；
|
||||
> 如果 Kubernetes 集群是在物理机上，可以安装 Porter（`https://porter.kubesphere.io`）负载均衡器对外暴露集群服务；
|
||||
> 如果在公有云上，可以安装和配置公有云支持的负载均衡器插件，然后创建 LoadBalancer 类型的网关，填入公网IP对应的 eip，会自动创建好负载均衡器，并将端口转发到网关。
|
||||
|
||||
### 安装 cert-manager
|
||||
|
||||
详细安装文档可以参考 [cert-manager](https://docs.cert-manager.io/en/latest/getting-started/install/kubernetes.html)。
|
||||
|
||||
> `cert-manager` 部署时会创建一个 `webhook` 来校验 `cert-manager` 相关对象是否符合格式，不过也会增加部署的复杂性。这里我们使用官方提供的一个 `no-webhook` 版本安装。
|
||||
|
||||
可以在 KubeSphere 右下角的工具箱中，打开 Web Kubectl。
|
||||
|
||||
|
||||
|
||||
在 Web Kubectl 执行下列命令安装 cert-manager：
|
||||
|
||||
```
|
||||
# Install the CustomResourceDefinitions and cert-manager itself
|
||||
kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v0.11.0/cert-manager-no-webhook.yaml
|
||||
```
|
||||
|
||||
### 创建 Issuer
|
||||
`Issuer` 是 cert-manager 中的概念，表示证书的签发者。在此实例中，我们使用免费的[ `letsencrypt`](https://letsencrypt.org/) 来获取TLS证书。
|
||||
|
||||
|
||||
在 kubectl 中执行下面命令来创建一个`kubesphere-system`项目可用的 `Issuer`(注意修改项目和email信息)
|
||||
```
|
||||
kubectl -n kubesphere-system create -f - <<EOF
|
||||
apiVersion: cert-manager.io/v1alpha2
|
||||
kind: Issuer
|
||||
metadata:
|
||||
name: letsencrypt-prod
|
||||
namespace: kubesphere-system
|
||||
spec:
|
||||
acme:
|
||||
email: kubesphere@kubesphere.io
|
||||
privateKeySecretRef:
|
||||
name: letsencrypt-prod
|
||||
server: https://acme-v02.api.letsencrypt.org/directory
|
||||
solvers:
|
||||
- http01:
|
||||
ingress:
|
||||
class: nginx
|
||||
EOF
|
||||
```
|
||||
创建完成后，执行下面命令可以看到
|
||||
```
|
||||
[root@master ~]# kubectl -n kubesphere-system get issuers.cert-manager.io
|
||||
NAME AGE
|
||||
letsencrypt-prod 46m
|
||||
```
|
||||
|
||||
### 创建证书 `Certificate`
|
||||
在kubectl里执行下面命令创建
|
||||
```
|
||||
kubectl -n kubesphere-system create -f - <<EOF
|
||||
apiVersion: cert-manager.io/v1alpha2
|
||||
kind: Certificate
|
||||
metadata:
|
||||
name: staging-kubesphere-io
|
||||
namespace: kubesphere-system
|
||||
spec:
|
||||
commonName: staging.kubesphere.io
|
||||
dnsNames:
|
||||
- staging.kubesphere.io
|
||||
duration: 2160h
|
||||
issuerRef:
|
||||
name: letsencrypt-prod
|
||||
renewBefore: 360h
|
||||
secretName: staging-kubesphere-io
|
||||
EOF
|
||||
```
|
||||
`cert-manager` 会根据 `Certificate` 自动进行 `http01 challenge` 签发证书，在 `kubesphere-system` 下创建对应的 TLS 证书
|
||||
```
|
||||
[root@master ~]# kubectl -n kubesphere-system get secrets
|
||||
NAME TYPE DATA AGE
|
||||
staging-kubesphere-io kubernetes.io/tls 3 40m
|
||||
```
|
||||
|
||||
### 使用证书
|
||||
|
||||
证书签发完成后，确认对应的 TLS 证书已经在项目下创建，就可以在创建应用路由（Ingress）中使用证书了。如下，创建时选择对应的 TLS 证书即可
|
||||
|
||||
|
||||
|
||||
当创建 Ingress 完成后，即可通过浏览器 `https://staging.kubesphere.io` 访问 Ingress 代理的服务，本示例我们已给 KubeSphere Console 服务配置了该域名。
|
||||
|
||||
|
||||
|
||||
> KubeSphere (https://kubesphere.io) 是在 Kubernetes 之上构建的以应用为中心的多租户容器平台，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。KubeSphere 提供了运维友好的向导式操作界面，帮助企业快速构建一个强大和功能丰富的容器云平台。
|
||||
|
|
@ -10,26 +10,26 @@ list:
|
|||
icon: images/conferences/kubecon.svg
|
||||
bg: images/conferences/kubecon-bg.svg
|
||||
children:
|
||||
- name: 基于 Kubernetes 的 Serverless Jenkins — Jenkins X
|
||||
summary: 在云原生时代，应用模块不断被拆分，使得模块的数量不断上涨并且关系也越加复杂。企业在落地云原生技术的时候同事也需要有强大的 DevOps 手段，没有 DevOps 的云原生不可能是成功的。Jenkins X 是 CDF（持续交付基金会）与
|
||||
author: 夏润泽
|
||||
link: jenkins-x
|
||||
image:
|
||||
- name: Porter-面向裸金属环境的 Kubernetes 开源负载均衡器
|
||||
summary: 我们知道，在 Kubernetes 集群中可以使用 “LoadBalancer” 类型的服务将后端工作负载暴露在外部。云厂商通常为 Kubernetes 提供云上的 LB 插件，但这需要将集群部署在特定 IaaS 平台上。然而，许多企业用户通常都将 Kubernetes…
|
||||
author: 宋雪涛
|
||||
link: porter
|
||||
image: https://pek3b.qingstor.com/kubesphere-docs/png/20200611115347.png
|
||||
|
||||
- name: 云原生可观察性之日志管理
|
||||
summary: 日志通常含有非常有价值的信息，日志管理是云原生可观察性的重要组成部分。不同于物理机或虚拟机，在容器与 Kubernetes 环境中，日志有标准的输出方式(stdout…
|
||||
author: 霍秉杰，马丹
|
||||
link: logging
|
||||
image:
|
||||
image: https://pek3b.qingstor.com/kubesphere-docs/png/20200607224942.png
|
||||
|
||||
- name: Porter-面向裸金属环境的 Kubernetes 开源负载均衡器
|
||||
summary: 我们知道，在 Kubernetes 集群中可以使用 “LoadBalancer” 类型的服务将后端工作负载暴露在外部。云厂商通常为 Kubernetes 提供云上的 LB 插件，但这需要将集群部署在特定 IaaS 平台上。然而，许多企业用户通常都将 Kubernetes…
|
||||
author: 宋雪涛
|
||||
link: porter
|
||||
image:
|
||||
- name: 基于 Kubernetes 的 Serverless Jenkins — Jenkins X
|
||||
summary: 在云原生时代，应用模块不断被拆分，使得模块的数量不断上涨并且关系也越加复杂。企业在落地云原生技术的时候同事也需要有强大的 DevOps 手段，没有 DevOps 的云原生不可能是成功的。Jenkins X 是 CDF（持续交付基金会）与
|
||||
author: 夏润泽
|
||||
link: jenkins-x
|
||||
image: https://pek3b.qingstor.com/kubesphere-docs/png/20190930095450.png
|
||||
|
||||
- name: QCon 全球软件开发大会
|
||||
content:
|
||||
content:
|
||||
icon: images/conferences/qcon.svg
|
||||
bg: images/conferences/qcon-bg.svg
|
||||
children:
|
||||
|
|
@ -37,5 +37,5 @@ list:
|
|||
summary: 现在很多用户都会将自己的应用迁移到 Kubernetes 容器平台中。在 Kubernetes 容器平台中，存储是支撑用户应用的基石。随着用户不断的将自己的应用深度部署在 K8S 容器平台中，但是我们现有的 Kubernetes…
|
||||
author: 王欣
|
||||
link: csi
|
||||
image:
|
||||
---
|
||||
image: https://pek3b.qingstor.com/kubesphere-docs/png/20200611114611.png
|
||||
---
|
||||
|
|
|
|||
|
|
@ -8,15 +8,20 @@ snapshot: 'https://pek3b.qingstor.com/kubesphere-docs/png/20190930095713.png'
|
|||
我们知道，在 Kubernetes 集群中可以使用 “LoadBalancer” 类型的服务将后端工作负载暴露在外部。云厂商通常为 Kubernetes 提供云上的 LB 插件，但这需要将集群部署在特定 IaaS 平台上。然而，许多企业用户通常都将 Kubernetes 集群部署在裸机上，尤其是用于生产环境时。而且对于本地裸机集群，Kubernetes 不提供 LB 实施。Porter 是一个专为裸金属 Kubernetes 集群环境而设计的开源的负载均衡器项目，可完美地解决此类问题。
|
||||
|
||||
## Kubernetes 服务介绍
|
||||
|
||||
在 Kubernetes 集群中，网络是非常基础也非常重要的一部分。对于大规模的节点和容器来说，要保证网络的连通性、网络转发的高效，同时能做的 IP 和 Port 自动化分配和管理，并提供给用户非常直观和简单的方式来访问需要的应用，这是非常复杂且细致的设计。
|
||||
|
||||
Kubernetes 本身在这方面下了很大的功夫，它通过 CNI、Service、DNS、Ingress 等一系列概念，解决了服务发现、负载均衡的问题，也大大简化了用户的使用和配置。其中的 Service 是 Kubernetes 微服务的基础，Kubernetes 是通过 kube-proxy 这个组件来实现服务的。kube-proxy 运行在每个节点上，监听 API Server 中服务对象的变化，通过管理 iptables 来实现网络的转发。用户可以创建多种形式的 Service，比如基于 Label Selector 、Headless 或者 ExternalName 的 Service，kube-proxy 会为 Service 创建一个虚拟的 IP（即 Cluster IP），用于集群内部访问服务。
|
||||
|
||||
## 暴露服务的三种方式
|
||||
|
||||
如果需要从集群外部访问服务，即将服务暴露给用户使用，Kubernetes Service 本身提供了两种方式，一种是 NodePort，另外一种是 LoadBalancer。另外 Ingress 也是一种常用的暴露服务的方式。
|
||||
|
||||
### NodePort
|
||||
|
||||
如果将服务的类型设置为 NodePort，kube-proxy 就会为这个服务申请一个 30000 以上的端口号（默认情况下），然后在集群所有主机上配置 IPtables 规则，这样用户就能通过集群中的任意节点加上这个分配的端口号访问服务了，如下图
|
||||
|
||||
|
||||
|
||||
|
||||
NodePort 是最方便的暴露服务的方式，缺点也很明显：
|
||||
|
||||
|
|
@ -25,16 +30,20 @@ NodePort 是最方便的暴露服务的方式，缺点也很明显：
|
|||
3. NodePort 端口号一般都是用大端口，不容易记忆。
|
||||
|
||||
NodePort 设计之初就不是用于生产环境暴露服务的方式，所以默认端口都是一些大端口。
|
||||
|
||||
### LoadBalancer
|
||||
|
||||
LoadBalancer 是 Kubernetes 提倡的将服务暴露给外部的一种方式。但是这种方式需要借助于云厂商提供的负载均衡器才能实现，这也要求了 Kubernetes 集群必须在云厂商上部署。LoadBalancer 的原理如下：
|
||||
|
||||
|
||||
|
||||
|
||||
LoadBalancer 通过云厂商的 LB 插件实现，LB 插件基于 Kubernetes.io/cloud-provider 这个包实现，这个包会自动选择合适的后端暴露给 LB 插件，然后 LB 插件由此创建对应的负载均衡器，网络流量在云服务端就会被分流，就能够避免 NodePort 方式的单点故障和性能瓶颈。LoadBalancer 是 Kubernetes 设计的对外暴露服务的推荐方式，但是这种方式仅仅限于云厂商提供的 Kubernetes 服务上，对于物理部署或者非云环境下部署的 Kubernetes 集群，这一机制就存在局限性而无法使用。
|
||||
|
||||
### Ingress
|
||||
|
||||
Ingress 并不是 Kubernetes 服务本身提供的暴露方式，而是借助于软件实现的同时暴露多个服务的一种类似路由器的插件。Ingress 通过域名来区分不同服务，并且通过 annotation 的方式控制服务对外暴露的方式。其原理如下图：
|
||||
|
||||
|
||||
|
||||
|
||||
相比于 NodePort 和 LoadBalancer，Ingress 在企业业务场景中应该是使用的最多的，原因有：
|
||||
|
||||
|
|
@ -50,49 +59,57 @@ Ingress 并不是 Kubernetes 服务本身提供的暴露方式，而是借助于
|
|||
|
||||
## Porter 介绍
|
||||
|
||||
Porter 是 KubeSphere 团队研发的一款开源的基于 BGP 协议的云原生负载均衡器插件。它的主要特性有：
|
||||
[Porter](https://porterlb.io) 是 KubeSphere 团队研发的一款开源的基于 BGP 协议的云原生负载均衡器插件。它的主要特性有：
|
||||
|
||||
1. 基于路由器 ECMP 的负载均衡
|
||||
2. 基于 BGP 路由动态配置
|
||||
3. VIP 管理
|
||||
|
||||
Porter 的所有代码和文档已在 [GitHub](https://github.com/kubesphere/porter) 开源，欢迎大家关注(Star)和使用。
|
||||
|
||||
|
||||
Porter 的所有代码和文档已在 [GitHub](https://github.com/kubesphere/porter) 开源，欢迎大家关注 (Star) 和使用。
|
||||
|
||||
|
||||
## 如何快速部署使用
|
||||
|
||||
Porter 目前已在如下两种环境下进行过部署和测试，并将部署测试与使用步骤的详细文档记录在 GitHub，大家可以通过以下链接查看，建议大家动手部署实践一下。
|
||||
|
||||
- [在物理部署的 Kubernetes 集群上部署使用 Porter](https://github.com/kubesphere/porter/blob/master/doc/deploy_baremetal.md)
|
||||
- [在青云 QingCloud 云平台用模拟路由器的方式测试](https://github.com/kubesphere/porter/blob/master/doc/simulate_with_bird.md)
|
||||
- [在物理部署的 Kubernetes 集群上部署使用 Porter](https://github.com/kubesphere/porter/blob/master/doc/zh/deploy_baremetal.md)
|
||||
- [在云平台用模拟路由器的方式测试](https://github.com/kubesphere/porter/blob/master/doc/zh/simulate_with_bird.md)
|
||||
- [Layer2 的使用](https://github.com/kubesphere/porter/blob/master/doc/zh/layer2.md)
|
||||
|
||||
## 原理
|
||||
|
||||
### ECMP
|
||||
|
||||
ECMP（Equal-Cost Multi-Pathing，等价路由）即存在多条到达同一个目的地址的相同开销的路径。当设备支持等价路由时，发往该目的 IP 或者目的网段的三层转发流量就可以通过不同的路径分担，实现网络的负载均衡，并在其中某些路径出现故障时，由其它路径代替完成转发处理，实现路由冗余备份功能。如下图：
|
||||
|
||||
|
||||
|
||||
|
||||
借助于路由器（虚拟路由器），对于某一个IP（对应服务的VIP），ECMP能根据一定的Hash算法从已知的路由中来选择下一跳（Pod），从而实现负载均衡的目的。一般的路由器（虚拟路由器）都具备 ECMP 的能力，Porter 要做的就是查询 Kubernetes API Server，将一个服务对应的后端 Pod 信息通过路由的方式发送给路由器。
|
||||
|
||||
### BGP
|
||||
在Kubernetes中，Pod可能会漂移，对于路由器来说，一个服务VIP的下一跳是不固定的，等价路由的信息会经常更新。实际上我们参考 Calico，使用了 BGP（Border Gateway Protocol，边界网关协议）实现路由的广播。BGP 是互联网上一个核心的去中心化自治路由协议，在互联网领域用的比较多。BGP 不同于其他路由协议，BGP使用了L4来保证路由信息的安全更新。同时由于BGP的去中心化特性，很容易搭建一个高可用路由层，保证网络的持续性。
|
||||
|
||||
|
||||
上图简单描述了Porter中BGP的实现原理。图中左下是一个两节点的Kubernetes集群，集群上方是有两个路由器leaf1和leaf2，leaf连接了核心交换机层spine，也同样是两个。最右侧是用户，对应的路由器是border，border也连接了spine，用户和Kubernetes服务器三层是可达的。 Kubernetes集群中创建了Service，并且使用了Porter，Porter为其分配了一个1.1.1.1的vip（或者手工指定），Porter通过BGP告知leaf1和leaf2，访问1.1.1.1的下一跳可以是node1，也可以是node2。leaf一层也会将这个信息告知spine，spine的BGP经过计算得知访问1.1.1.1的下一跳是leaf1，leaf2。按照同样的逻辑，这个路由也会更新到border，这样用户访问1.1.1.1的完整路径就有了。同时，由于这个图中每一层都有HA，所以外界访问1.1.1.1的路径就有2*2*2*2=16条，流量能够在整个网络中被分流，并且任意一层一个路由器宕机都不会影响用户的访问。
|
||||
在Kubernetes中，Pod可能会漂移，对于路由器来说，一个服务VIP的下一跳是不固定的，等价路由的信息会经常更新。实际上我们参考 Calico，使用了 BGP（Border Gateway Protocol，边界网关协议）实现路由的广播。BGP 是互联网上一个核心的去中心化自治路由协议，在互联网领域用的比较多。BGP 不同于其他路由协议，BGP使用了L4来保证路由信息的安全更新。同时由于BGP的去中心化特性，很容易搭建一个高可用路由层，保证网络的持续性。
|
||||
|
||||
|
||||
|
||||
上图简单描述了 Porter 中 BGP 的实现原理。图中左下是一个两节点的 Kubernetes 集群，集群上方是有两个路由器 leaf1 和 leaf2，leaf 连接了核心交换机层 spine，也同样是两个。最右侧是用户，对应的路由器是 border，border 也连接了 spine，用户和 Kubernetes 服务器三层是可达的。 Kubernetes 集群中创建了 Service，并且使用了 Porter，Porter 为其分配了一个 **1.1.1.1** 的 VIP（或者手工指定），Porter 通过 BGP 告知 leaf1 和 leaf2，访问 **1.1.1.1** 的下一跳可以是 node1，也可以是 node2。leaf 一层也会将这个信息告知 spine，spine 的 BGP 经过计算得知访问 **1.1.1.1** 的下一跳是 leaf1，leaf2。按照同样的逻辑，这个路由也会更新到 border，这样用户访问 **1.1.1.1** 的完整路径就有了。同时，由于这个图中每一层都有HA，所以外界访问 **1.1.1.1** 的路径就有 `2*2*2*2`= **16** 条，流量能够在整个网络中被分流，并且任意一层一个路由器宕机都不会影响用户的访问。
|
||||
|
||||
## 架构
|
||||
|
||||
|
||||
|
||||
|
||||
Porter有两个组件，一个核心控制器和一个部署在所有节点上的agent。核心控制器主要功能有：
|
||||
1. 监控集群中的Service以及对应的endpoints，获取pod漂移信息
|
||||
2. VIP存储与分配
|
||||
3. 与外界建立BGP协议，广播路由
|
||||
Porter 有两个组件，一个核心控制器和一个部署在所有节点上的 agent。核心控制器主要功能有：
|
||||
1. 监控集群中的 Service 以及对应的 endpoints，获取 Pod漂移信息
|
||||
2. VIP 存储与分配
|
||||
3. 与外界建立 BGP 协议，广播路由
|
||||
|
||||
|
||||
|
||||
|
||||
上图展示了 Porter 核心控制器的工作原理。
|
||||
|
||||
agent 则是一个轻量级组件，用于监控VIP资源，增加Iptables规则让外部流量能够访问VIP，默认情况下外部流量访问VIP会被内核中的Forward表Drop掉
|
||||
Agent 则是一个轻量级组件，用于监控 VIP 资源，增加 Iptables 规则让外部流量能够访问 VIP，默认情况下外部流量访问 VIP 会被内核中的 Forward 表 Drop 掉
|
||||
|
||||
## 面向云原生的设计
|
||||
|
||||
|
|
@ -100,28 +117,28 @@ Porter 中的所有资源都是 CRD，包括 VIP、BGPPeer、BGPConfig 等。对
|
|||
|
||||
## 使用注意事项
|
||||
|
||||
用户访问 VIP 的流量会通过 BGP 到达 Kubernetes 集群中的某一个节点，因为 Porter广播路由的路也是node而不是具体的podip，podip外部不可访问，后续node到pod的路由是由kube-proxy维护的。如下图：
|
||||
用户访问 VIP 的流量会通过 BGP 到达 Kubernetes 集群中的某一个节点，因为 Porter 广播路由的路也是node而不是具体的 Pod IP，Pod IP 外部不可访问，后续 Node 到 Pod 的路由是由 kube-proxy 维护的。如下图：
|
||||
|
||||
|
||||
|
||||
|
||||
流量被 SNAT 之后随机发送给某一个pod。由于Porter会根据Service Endpoints的变化动态调整路由，确保下一跳的node节点一定有pod存在，所以我们可以更改kube-proxy这一个默认行为。在Service上设置ExternalTrafficPolicy=local，达到下面的效果：
|
||||
流量被 SNAT 之后随机发送给某一个 Pod。由于 Porter 会根据 Service Endpoints 的变化动态调整路由，确保下一跳的 Node 节点一定有 Pod 存在，所以我们可以更改 kube-proxy 这一个默认行为。在 Service 上设置 **ExternalTrafficPolicy=local**，达到下面的效果：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这样做有两个好处：
|
||||
|
||||
1. SourceIP不会NAT
|
||||
1. SourceIP 不会 NAT
|
||||
2. 流量直接走本地，网络路径少一跳
|
||||
|
||||
## 未来计划
|
||||
|
||||
1. 支持其他简单路由协议
|
||||
2. 更加方便的VIP管理
|
||||
3. BGP的policy支持
|
||||
4. 在Kubesphere集成，提供UI
|
||||
|
||||
|
||||
|
||||
|
||||
2. 更加方便的 VIP 管理
|
||||
3. BGP 的 Policy 支持
|
||||
4. 在 Kubesphere 集成，提供 Porter UI
|
||||
|
||||
## 相关资源
|
||||
|
||||
- [KubeCon Shanghai: Porter - An Open Source Load Balancer for Bare Metal Kubernetes](https://www.youtube.com/watch?v=EjU1yAVxXYQ)
|
||||
- [Porter 官网](https://porterlb.io)
|
||||
|
|
|
|||
|
|
@ -7,28 +7,83 @@ name: 开源项目
|
|||
groups:
|
||||
- name: 容器平台
|
||||
children:
|
||||
- title: KubeSphere 容器平台
|
||||
icon: 'images/kubesphere.svg'
|
||||
link: ''
|
||||
- title: "KubeSphere 容器平台"
|
||||
icon: 'images/projects/kubesphere.svg'
|
||||
link: 'https://github.com/kubesphere/kubesphere'
|
||||
description: 基于 Kubernetes 之上构建的以应用为中心的多租户容器平台，支持部署运行在任何基础设施之上，提供简单易用的操作界面以及向导式 UI，旨在解决 Kubernetes 的存储、网络、安全与易用性等痛点。
|
||||
|
||||
|
||||
- name: 应用管理
|
||||
children:
|
||||
- title: OpenPitrix 多云应用管理平台
|
||||
icon: ''
|
||||
link: ''
|
||||
icon: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200607231502.png'
|
||||
link: 'https://github.com/openpitrix/openpitrix'
|
||||
description: 开源的多云应用管理平台，用来在多云环境下打包、部署和管理不同类型的应用，包括传统应用、微服务应用以及 Serverless 应用等，其中云平台包括 AWS、Kubernetes、QingCloud、VMWare。
|
||||
|
||||
- name: 服务代理
|
||||
children:
|
||||
- title: Porter 负载均衡器
|
||||
icon: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200608102707.png'
|
||||
link: 'https://porterlb.io'
|
||||
description: 适用于物理部署 Kubernetes 环境的负载均衡器插件，Porter 使用物理交换机实现，利用 BGP 和 ECMP 从而达到性能最优和高可用性，提供用户在物理环境暴露 LoadBalancer 类型服务与云上获得一致性体验。
|
||||
|
||||
- name: 安装部署
|
||||
children:
|
||||
- title: KubeKey
|
||||
icon: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200608103108.png'
|
||||
link: 'https://github.com/kubesphere/kubekey'
|
||||
description: KubeKey 是 Kubernetes 和 KubeSphere 的下一代 Installer（安装程序），旨在更方便、快速、高效和灵活地安装 Kubernetes 与 KubeSphere。KubeKey 摒弃了原来 Ansible 带来的依赖问题，用 Go 重写，支持单独 Kubernetes 或整体安装 KubeSphere。
|
||||
|
||||
- name: 日志管理
|
||||
children:
|
||||
- title: Fluentbit Operator
|
||||
icon: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200608104816.png'
|
||||
link: 'https://github.com/kubesphere/fluentbit-operator'
|
||||
description: Fluentbit Operator 极大地方便了 Fluent Bit 在 Kubernetes 之上的部署，并且基于 Fluent Bit 提供了非常灵活日志管理，提供了 Fluent Bit 运维管理、自定义配置、动态加载等功能。
|
||||
|
||||
- name: 消息通知
|
||||
children:
|
||||
- title: Notification Manager
|
||||
icon: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200608105148.png'
|
||||
link: 'https://github.com/kubesphere/notification-manager'
|
||||
description: Notification Manager 管理多租户 Kubernetes 环境中的消息通知。它支持接收来自不同发送方的告警或通知，然后根据告警/通知的租户标签 (如 “namespace”)向平台的各个租户接收方发送通知，支持邮件、企业微信、Slack 等通知渠道，下个版本支持 Webhook。
|
||||
|
||||
- name: Kubernetes 事件
|
||||
children:
|
||||
- title: kube-events
|
||||
icon: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200608111002.png'
|
||||
link: 'https://github.com/kubesphere/kube-events'
|
||||
description: Kube-events 围绕 Kubernetes 事件（Events），支持对事件进行多维度处理，例如向接收方发送事件，针对事件发出告警通知。在其中一些维度中，Kube-events 还提供了可配置的过滤规则以满足不同的业务需求。
|
||||
|
||||
- name: 告警系统
|
||||
children:
|
||||
- title: Alerting System
|
||||
icon: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200608111200.png'
|
||||
link: 'https://github.com/kubesphere/alert'
|
||||
description: KubeSphere Alert 是一种企业级的通用高性能报警系统。
|
||||
|
||||
- name: CI/CD
|
||||
children:
|
||||
- title: S2i-operator
|
||||
icon: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200608111455.png'
|
||||
link: 'https://github.com/kubesphere/s2ioperator'
|
||||
description: Source-to-Image (S2I) Operator 是一个基于 Kubernetes CRD 的控制器，它为声明式的 CI/CD 流水线提供了简单的 Kubernetes 风格的资源。S2I Operator 通过向容器镜像中注入源代码，并让容器准备执行源代码来创建准备运行的镜像。
|
||||
|
||||
- name: 前端设计
|
||||
children:
|
||||
- title: kube-design
|
||||
icon: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200608114816.png'
|
||||
link: 'https://github.com/kubesphere/kube-design'
|
||||
description: kube-design 是为 KubeSphere Console 前端创建的一组 React 组件库。如果您想开发与扩展 KubeSphere 控制台（Console）的前端，这个库在定制 KubeSphere 前端时会非常有用。
|
||||
|
||||
- name: 存储插件
|
||||
children:
|
||||
- title: QingStor-CSI
|
||||
icon: ''
|
||||
link: ''
|
||||
icon: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200608111848.png'
|
||||
link: 'https://github.com/yunify/qingstor-csi'
|
||||
description: QingStor CSI 插件实现 CSI 接口，使容器编排平台（如 Kubernetes）能够使用 NeonSAN 分布式存储的资源。目前，QingStor CSI 插件实现了存储卷管理和快照管理功能，并在 Kubernetes v1.12 环境中通过了 CSI Sanity 测试。
|
||||
|
||||
- title: QingCloud-CSI
|
||||
icon: ''
|
||||
link: ''
|
||||
description: QingCloud CSI 插件实现了 CSI 接口，并使容器管理平台能够使用 QingCloud 云平台的块存储资源。目前，QingCloud CSI 插件已经在 Kubernetes v1.14/v1.15 环境中通过了 CSI 测试。
|
||||
|
||||
---
|
||||
- title: QingCloud-CSI
|
||||
icon: 'https://pek3b.qingstor.com/kubesphere-docs/png/20200608112327.png'
|
||||
link: 'https://github.com/yunify/qingcloud-csi'
|
||||
description: QingCloud CSI 插件实现了 CSI 接口，并使容器管理平台能够使用 QingCloud 云平台的块存储资源。目前，QingCloud CSI 插件已经在 Kubernetes v1.14/v1.15 环境中通过了 CSI 测试。
|
||||
---
|
||||
|
|
|
|||
|
|
@ -57,3 +57,5 @@ footer:
|
|||
link: https://github.com/kubesphere/kubesphere/blob/master/docs/roadmap.md
|
||||
- content: 中国站
|
||||
link: https://kubesphere.com.cn/
|
||||
- content: 中文论坛
|
||||
link: https://kubesphere.com.cn/forum
|
||||
|
|
|
|||
Loading…
Reference in New Issue