# 部署node節點
Kubernetes node節點包含如下組件:
+ Flanneld:參考我之前寫的文章[Kubernetes基于Flannel的網絡配置](https://jimmysong.io/posts/kubernetes-network-config/),之前沒有配置TLS,現在需要在service配置文件中增加TLS配置,安裝過程請參考上一節[安裝flannel網絡插件](flannel-installation.md)。
+ Docker1.12.5:docker的安裝很簡單,這里也不說了,但是需要注意docker的配置。
+ kubelet:直接用二進制文件安裝
+ kube-proxy:直接用二進制文件安裝
**注意**:每臺 node 上都需要安裝 flannel,master 節點上可以不安裝。
**步驟簡介**
1. 確認在上一步中我們安裝配置的網絡插件flannel已啟動且運行正常
2. 安裝配置docker后啟動
3. 安裝配置kubelet、kube-proxy后啟動
4. 驗證
## 目錄和文件
我們再檢查一下三個節點上,經過前幾步操作我們已經創建了如下的證書和配置文件。
``` bash
$ ls /etc/kubernetes/ssl
admin-key.pem admin.pem ca-key.pem ca.pem kube-proxy-key.pem kube-proxy.pem kubernetes-key.pem kubernetes.pem
$ ls /etc/kubernetes/
apiserver bootstrap.kubeconfig config controller-manager kubelet kube-proxy.kubeconfig proxy scheduler ssl token.csv
```
## 配置Docker
> 如果您使用yum的方式安裝的flannel則不需要執行mk-docker-opts.sh文件這一步,參考Flannel官方文檔中的[Docker Integration](https://github.com/coreos/flannel/blob/master/Documentation/running.md)。
如果你不是使用yum安裝的flannel,那么需要下載flannel github release中的tar包,解壓后會獲得一個**mk-docker-opts.sh**文件,到[flannel release](https://github.com/coreos/flannel/releases)頁面下載對應版本的安裝包,該腳本見[mk-docker-opts.sh](https://github.com/rootsongjc/kubernetes-handbook/tree/master/tools/flannel/mk-docker-opts.sh),因為我們使用yum安裝所以不需要執行這一步。
這個文件是用來`Generate Docker daemon options based on flannel env file`。
使用`systemctl`命令啟動flanneld后,會自動執行`./mk-docker-opts.sh -i`生成如下兩個文件環境變量文件:
- /run/flannel/subnet.env
```ini
FLANNEL_NETWORK=172.30.0.0/16
FLANNEL_SUBNET=172.30.46.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
```
- /run/docker_opts.env
```ini
DOCKER_OPT_BIP="--bip=172.30.46.1/24"
DOCKER_OPT_IPMASQ="--ip-masq=true"
DOCKER_OPT_MTU="--mtu=1450"
```
Docker將會讀取這兩個環境變量文件作為容器啟動參數。
**注意:**不論您用什么方式安裝的flannel,下面這一步是必不可少的。
**yum方式安裝的flannel**
修改docker的配置文件`/usr/lib/systemd/system/docker.service`,增加一條環境變量配置:
```ini
EnvironmentFile=-/run/flannel/docker
```
`/run/flannel/docker`文件是flannel啟動后自動生成的,其中包含了docker啟動時需要的參數。
**二進制方式安裝的flannel**
修改docker的配置文件`/usr/lib/systemd/system/docker.service`,增加如下幾條環境變量配置:
```ini
EnvironmentFile=-/run/docker_opts.env
EnvironmentFile=-/run/flannel/subnet.env
```
這兩個文件是`mk-docker-opts.sh`腳本生成環境變量文件默認的保存位置,docker啟動的時候需要加載這幾個配置文件才可以加入到flannel創建的虛擬網絡里。
所以不論您使用何種方式安裝的flannel,將以下配置加入到`docker.service`中可確保萬無一失。
```ini
EnvironmentFile=-/run/flannel/docker
EnvironmentFile=-/run/docker_opts.env
EnvironmentFile=-/run/flannel/subnet.env
EnvironmentFile=-/etc/sysconfig/docker
EnvironmentFile=-/etc/sysconfig/docker-storage
EnvironmentFile=-/etc/sysconfig/docker-network
EnvironmentFile=-/run/docker_opts.env
```
請參考[docker.service](https://github.com/rootsongjc/kubernetes-handbook/blob/master/systemd/docker.service)中的配置。
### 啟動docker
重啟了docker后還要重啟kubelet,這時又遇到問題,kubelet啟動失敗。報錯:
```bash
Mar 31 16:44:41 test-002.jimmysong.io kubelet[81047]: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"
```
這是kubelet與docker的**cgroup driver**不一致導致的,kubelet啟動的時候有個`—cgroup-driver`參數可以指定為"cgroupfs"或者“systemd”。
```bash
--cgroup-driver string Driver that the kubelet uses to manipulate cgroups on the host. Possible values: 'cgroupfs', 'systemd' (default "cgroupfs")
```
配置docker的service配置文件`/usr/lib/systemd/system/docker.service`,設置`ExecStart`中的`--exec-opt native.cgroupdriver=systemd`。
## 安裝和配置kubelet
**kubernets1.8**
相對于kubernetes1.6集群必須進行的配置有:
對于kuberentes1.8集群,必須關閉swap,否則kubelet啟動將失敗。
修改`/etc/fstab`將,swap系統注釋掉。
---
kubelet 啟動時向 kube-apiserver 發送 TLS bootstrapping 請求,需要先將 bootstrap token 文件中的 kubelet-bootstrap 用戶賦予 system:node-bootstrapper cluster 角色(role),
然后 kubelet 才能有權限創建認證請求(certificate signing requests):
``` bash
cd /etc/kubernetes
kubectl create clusterrolebinding kubelet-bootstrap \
--clusterrole=system:node-bootstrapper \
--user=kubelet-bootstrap
```
+ `--user=kubelet-bootstrap` 是在 `/etc/kubernetes/token.csv` 文件中指定的用戶名,同時也寫入了 `/etc/kubernetes/bootstrap.kubeconfig` 文件;
---
kubelet 通過認證后向 kube-apiserver 發送 register node 請求,需要先將 `kubelet-nodes` 用戶賦予 `system:node` cluster角色(role) 和 `system:nodes` 組(group),
然后 kubelet 才能有權限創建節點請求:
``` bash
kubectl create clusterrolebinding kubelet-nodes \
--clusterrole=system:node \
--group=system:nodes
```
### 下載最新的kubelet和kube-proxy二進制文件
注意請下載對應的Kubernetes版本的安裝包。
``` bash
wget https://dl.k8s.io/v1.6.0/kubernetes-server-linux-amd64.tar.gz
tar -xzvf kubernetes-server-linux-amd64.tar.gz
cd kubernetes
tar -xzvf kubernetes-src.tar.gz
cp -r ./server/bin/{kube-proxy,kubelet} /usr/local/bin/
```
### 創建kubelet的service配置文件
文件位置`/usr/lib/systemd/system/kubelet.service`。
```ini
[Unit]
Description=Kubernetes Kubelet Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=docker.service
Requires=docker.service
[Service]
WorkingDirectory=/var/lib/kubelet
EnvironmentFile=-/etc/kubernetes/config
EnvironmentFile=-/etc/kubernetes/kubelet
ExecStart=/usr/local/bin/kubelet \
$KUBE_LOGTOSTDERR \
$KUBE_LOG_LEVEL \
$KUBELET_API_SERVER \
$KUBELET_ADDRESS \
$KUBELET_PORT \
$KUBELET_HOSTNAME \
$KUBE_ALLOW_PRIV \
$KUBELET_POD_INFRA_CONTAINER \
$KUBELET_ARGS
Restart=on-failure
[Install]
WantedBy=multi-user.target
```
kubelet的配置文件`/etc/kubernetes/kubelet`。其中的IP地址更改為你的每臺node節點的IP地址。
**注意:**在啟動kubelet之前,需要先手動創建`/var/lib/kubelet`目錄。
下面是kubelet的配置文件`/etc/kubernetes/kubelet`:
**kubernetes1.8**
相對于kubenrete1.6的配置變動:
- 對于kuberentes1.8集群中的kubelet配置,取消了`KUBELET_API_SERVER`的配置,而改用kubeconfig文件來定義master地址,所以請注釋掉`KUBELET_API_SERVER`配置。
``` bash
###
## kubernetes kubelet (minion) config
#
## The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces)
KUBELET_ADDRESS="--address=172.20.0.113"
#
## The port for the info server to serve on
#KUBELET_PORT="--port=10250"
#
## You may leave this blank to use the actual hostname
KUBELET_HOSTNAME="--hostname-override=172.20.0.113"
#
## location of the api-server
## COMMENT THIS ON KUBERNETES 1.8+
KUBELET_API_SERVER="--api-servers=http://172.20.0.113:8080"
#
## pod infrastructure container
KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=jimmysong/pause-amd64:3.0"
#
## Add your own!
KUBELET_ARGS="--cgroup-driver=systemd --cluster-dns=10.254.0.2 --experimental-bootstrap-kubeconfig=/etc/kubernetes/bootstrap.kubeconfig --kubeconfig=/etc/kubernetes/kubelet.kubeconfig --require-kubeconfig --cert-dir=/etc/kubernetes/ssl --cluster-domain=cluster.local --hairpin-mode promiscuous-bridge --serialize-image-pulls=false"
```
+ 如果使用systemd方式啟動,則需要額外增加兩個參數`--runtime-cgroups=/systemd/system.slice --kubelet-cgroups=/systemd/system.slice`
+ `--experimental-bootstrap-kubeconfig` 在1.9版本已經變成了`--bootstrap-kubeconfig`
+ `--address` 不能設置為 `127.0.0.1`,否則后續 Pods 訪問 kubelet 的 API 接口時會失敗,因為 Pods 訪問的 `127.0.0.1` 指向自己而不是 kubelet;
+ 如果設置了 `--hostname-override` 選項,則 `kube-proxy` 也需要設置該選項,否則會出現找不到 Node 的情況;
+ `"--cgroup-driver` 配置成 `systemd`,不要使用`cgroup`,否則在 CentOS 系統中 kubelet 將啟動失敗(保持docker和kubelet中的cgroup driver配置一致即可,不一定非使用`systemd`)。
+ `--experimental-bootstrap-kubeconfig` 指向 bootstrap kubeconfig 文件,kubelet 使用該文件中的用戶名和 token 向 kube-apiserver 發送 TLS Bootstrapping 請求;
+ 管理員通過了 CSR 請求后,kubelet 自動在 `--cert-dir` 目錄創建證書和私鑰文件(`kubelet-client.crt` 和 `kubelet-client.key`),然后寫入 `--kubeconfig` 文件;
+ 建議在 `--kubeconfig` 配置文件中指定 `kube-apiserver` 地址,如果未指定 `--api-servers` 選項,則必須指定 `--require-kubeconfig` 選項后才從配置文件中讀取 kube-apiserver 的地址,否則 kubelet 啟動后將找不到 kube-apiserver (日志中提示未找到 API Server),`kubectl get nodes` 不會返回對應的 Node 信息; `--require-kubeconfig` 在1.10版本被移除,參看[PR](https://github.com/kubernetes/kops/pull/4357/commits/30b10cb1c8c9d8d67fdf6371f1fda952a2b02004);
+ `--cluster-dns` 指定 kubedns 的 Service IP(可以先分配,后續創建 kubedns 服務時指定該 IP),`--cluster-domain` 指定域名后綴,這兩個參數同時指定后才會生效;
+ `--cluster-domain` 指定 pod 啟動時 `/etc/resolve.conf` 文件中的 `search domain` ,起初我們將其配置成了 `cluster.local.`,這樣在解析 service 的 DNS 名稱時是正常的,可是在解析 headless service 中的 FQDN pod name 的時候卻錯誤,因此我們將其修改為 `cluster.local`,去掉最后面的 ”點號“ 就可以解決該問題,關于 kubernetes 中的域名/服務名稱解析請參見我的另一篇文章。
+ `--kubeconfig=/etc/kubernetes/kubelet.kubeconfig `中指定的`kubelet.kubeconfig`文件在第一次啟動kubelet之前并不存在,請看下文,當通過CSR請求后會自動生成`kubelet.kubeconfig`文件,如果你的節點上已經生成了`~/.kube/config`文件,你可以將該文件拷貝到該路徑下,并重命名為`kubelet.kubeconfig`,所有node節點可以共用同一個kubelet.kubeconfig文件,這樣新添加的節點就不需要再創建CSR請求就能自動添加到kubernetes集群中。同樣,在任意能夠訪問到kubernetes集群的主機上使用`kubectl --kubeconfig`命令操作集群時,只要使用`~/.kube/config`文件就可以通過權限認證,因為這里面已經有認證信息并認為你是admin用戶,對集群擁有所有權限。
+ `KUBELET_POD_INFRA_CONTAINER` 是基礎鏡像容器,這里我用的是私有鏡像倉庫地址,**大家部署的時候需要修改為自己的鏡像**。我上傳了一個到時速云上,可以直接 `docker pull index.tenxcloud.com/jimmy/pod-infrastructure` 下載。`pod-infrastructure`鏡像是Redhat制作的,大小接近80M,下載比較耗時,其實該鏡像并不運行什么具體進程,可以使用Google的pause鏡像`gcr.io/google_containers/pause-amd64:3.0`,這個鏡像只有300多K,或者通過DockerHub下載`jimmysong/pause-amd64:3.0`。
完整 unit 見 [kubelet.service](../systemd/kubelet.service)
### 啟動kublet
``` bash
systemctl daemon-reload
systemctl enable kubelet
systemctl start kubelet
systemctl status kubelet
```
### 通過kublet的TLS證書請求
kubelet 首次啟動時向 kube-apiserver 發送證書簽名請求,必須通過后 kubernetes 系統才會將該 Node 加入到集群。
查看未授權的 CSR 請求
``` bash
$ kubectl get csr
NAME AGE REQUESTOR CONDITION
csr-2b308 4m kubelet-bootstrap Pending
$ kubectl get nodes
No resources found.
```
通過 CSR 請求
``` bash
$ kubectl certificate approve csr-2b308
certificatesigningrequest "csr-2b308" approved
$ kubectl get nodes
NAME STATUS AGE VERSION
10.64.3.7 Ready 49m v1.6.1
```
自動生成了 kubelet kubeconfig 文件和公私鑰
``` bash
$ ls -l /etc/kubernetes/kubelet.kubeconfig
-rw------- 1 root root 2284 Apr 7 02:07 /etc/kubernetes/kubelet.kubeconfig
$ ls -l /etc/kubernetes/ssl/kubelet*
-rw-r--r-- 1 root root 1046 Apr 7 02:07 /etc/kubernetes/ssl/kubelet-client.crt
-rw------- 1 root root 227 Apr 7 02:04 /etc/kubernetes/ssl/kubelet-client.key
-rw-r--r-- 1 root root 1103 Apr 7 02:07 /etc/kubernetes/ssl/kubelet.crt
-rw------- 1 root root 1675 Apr 7 02:07 /etc/kubernetes/ssl/kubelet.key
```
假如你更新kubernetes的證書,只要沒有更新`token.csv`,當重啟kubelet后,該node就會自動加入到kuberentes集群中,而不會重新發送`certificaterequest`,也不需要在master節點上執行`kubectl certificate approve`操作。前提是不要刪除node節點上的`/etc/kubernetes/ssl/kubelet*`和`/etc/kubernetes/kubelet.kubeconfig`文件。否則kubelet啟動時會提示找不到證書而失敗。
**注意:**如果啟動kubelet的時候見到證書相關的報錯,有個trick可以解決這個問題,可以將master節點上的`~/.kube/config`文件(該文件在[安裝kubectl命令行工具](kubectl-installation.md)這一步中將會自動生成)拷貝到node節點的`/etc/kubernetes/kubelet.kubeconfig`位置,這樣就不需要通過CSR,當kubelet啟動后就會自動加入的集群中。
## 配置 kube-proxy
**安裝conntrack**
```bash
yum install -y conntrack-tools
```
**創建 kube-proxy 的service配置文件**
文件路徑`/usr/lib/systemd/system/kube-proxy.service`。
```ini
[Unit]
Description=Kubernetes Kube-Proxy Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=network.target
[Service]
EnvironmentFile=-/etc/kubernetes/config
EnvironmentFile=-/etc/kubernetes/proxy
ExecStart=/usr/local/bin/kube-proxy \
$KUBE_LOGTOSTDERR \
$KUBE_LOG_LEVEL \
$KUBE_MASTER \
$KUBE_PROXY_ARGS
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
```
kube-proxy配置文件`/etc/kubernetes/proxy`。
``` bash
###
# kubernetes proxy config
# default config should be adequate
# Add your own!
KUBE_PROXY_ARGS="--bind-address=172.20.0.113 --hostname-override=172.20.0.113 --kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig --cluster-cidr=10.254.0.0/16"
```
+ `--hostname-override` 參數值必須與 kubelet 的值一致,否則 kube-proxy 啟動后會找不到該 Node,從而不會創建任何 iptables 規則;
+ kube-proxy 根據 `--cluster-cidr` 判斷集群內部和外部流量,指定 `--cluster-cidr` 或 `--masquerade-all` 選項后 kube-proxy 才會對訪問 Service IP 的請求做 SNAT;
+ `--kubeconfig` 指定的配置文件嵌入了 kube-apiserver 的地址、用戶名、證書、秘鑰等請求和認證信息;
+ 預定義的 RoleBinding `cluster-admin` 將User `system:kube-proxy` 與 Role `system:node-proxier` 綁定,該 Role 授予了調用 `kube-apiserver` Proxy 相關 API 的權限;
完整 unit 見 [kube-proxy.service](../systemd/kube-proxy.service)
### 啟動 kube-proxy
``` bash
systemctl daemon-reload
systemctl enable kube-proxy
systemctl start kube-proxy
systemctl status kube-proxy
```
## 驗證測試
我們創建一個nginx的service試一下集群是否可用。
```bash
$ kubectl run nginx --replicas=2 --labels="run=load-balancer-example" --image=nginx --port=80
deployment "nginx" created
$ kubectl expose deployment nginx --type=NodePort --name=example-service
service "example-service" exposed
$ kubectl describe svc example-service
Name: example-service
Namespace: default
Labels: run=load-balancer-example
Annotations: <none>
Selector: run=load-balancer-example
Type: NodePort
IP: 10.254.62.207
Port: <unset> 80/TCP
NodePort: <unset> 32724/TCP
Endpoints: 172.30.60.2:80,172.30.94.2:80
Session Affinity: None
Events: <none>
$ curl "10.254.62.207:80"
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
```
訪問以下任何一個地址都可以得到nginx的頁面。
- 172.20.0.113:32724
- 172.20.0.114:32724
- 172.20.0.115:32724

## 參考
- [Kubelet 的認證授權](../guide/kubelet-authentication-authorization.md)
- 序言
- 云原生
- 云原生(Cloud Native)的定義
- CNCF - 云原生計算基金會簡介
- CNCF章程
- 云原生的設計哲學
- Play with Kubernetes
- 快速部署一個云原生本地實驗環境
- Kubernetes與云原生應用概覽
- 云原生應用之路——從Kubernetes到Cloud Native
- 云原生編程語言
- 云原生編程語言Ballerina
- 云原生編程語言Pulumi
- 云原生的未來
- Kubernetes架構
- 設計理念
- Etcd解析
- 開放接口
- CRI - Container Runtime Interface(容器運行時接口)
- CNI - Container Network Interface(容器網絡接口)
- CSI - Container Storage Interface(容器存儲接口)
- Kubernetes中的網絡
- Kubernetes中的網絡解析——以flannel為例
- Kubernetes中的網絡解析——以calico為例
- 具備API感知的網絡和安全性管理開源軟件Cilium
- Cilium架構設計與概念解析
- 資源對象與基本概念解析
- Pod狀態與生命周期管理
- Pod概覽
- Pod解析
- Init容器
- Pause容器
- Pod安全策略
- Pod的生命周期
- Pod Hook
- Pod Preset
- Pod中斷與PDB(Pod中斷預算)
- 集群資源管理
- Node
- Namespace
- Label
- Annotation
- Taint和Toleration(污點和容忍)
- 垃圾收集
- 控制器
- Deployment
- StatefulSet
- DaemonSet
- ReplicationController和ReplicaSet
- Job
- CronJob
- Horizontal Pod Autoscaling
- 自定義指標HPA
- 準入控制器(Admission Controller)
- 服務發現
- Service
- Ingress
- Traefik Ingress Controller
- 身份與權限控制
- ServiceAccount
- RBAC——基于角色的訪問控制
- NetworkPolicy
- 存儲
- Secret
- ConfigMap
- ConfigMap的熱更新
- Volume
- Persistent Volume(持久化卷)
- Storage Class
- 本地持久化存儲
- 集群擴展
- 使用自定義資源擴展API
- 使用CRD擴展Kubernetes API
- Aggregated API Server
- APIService
- Service Catalog
- 資源調度
- QoS(服務質量等級)
- 用戶指南
- 資源對象配置
- 配置Pod的liveness和readiness探針
- 配置Pod的Service Account
- Secret配置
- 管理namespace中的資源配額
- 命令使用
- Docker用戶過度到kubectl命令行指南
- kubectl命令概覽
- kubectl命令技巧大全
- 使用etcdctl訪問kubernetes數據
- 集群安全性管理
- 管理集群中的TLS
- kubelet的認證授權
- TLS bootstrap
- 創建用戶認證授權的kubeconfig文件
- IP偽裝代理
- 使用kubeconfig或token進行用戶身份認證
- Kubernetes中的用戶與身份認證授權
- Kubernetes集群安全性配置最佳實踐
- 訪問Kubernetes集群
- 訪問集群
- 使用kubeconfig文件配置跨集群認證
- 通過端口轉發訪問集群中的應用程序
- 使用service訪問群集中的應用程序
- 從外部訪問Kubernetes中的Pod
- Cabin - Kubernetes手機客戶端
- Kubernetic - Kubernetes桌面客戶端
- Kubernator - 更底層的Kubernetes UI
- 在Kubernetes中開發部署應用
- 適用于kubernetes的應用開發部署流程
- 遷移傳統應用到Kubernetes中——以Hadoop YARN為例
- 最佳實踐概覽
- 在CentOS上部署Kubernetes集群
- 創建TLS證書和秘鑰
- 創建kubeconfig文件
- 創建高可用etcd集群
- 安裝kubectl命令行工具
- 部署master節點
- 安裝flannel網絡插件
- 部署node節點
- 安裝kubedns插件
- 安裝dashboard插件
- 安裝heapster插件
- 安裝EFK插件
- 生產級的Kubernetes簡化管理工具kubeadm
- 使用kubeadm在Ubuntu Server 16.04上快速構建測試集群
- 服務發現與負載均衡
- 安裝Traefik ingress
- 分布式負載測試
- 網絡和集群性能測試
- 邊緣節點配置
- 安裝Nginx ingress
- 安裝配置DNS
- 安裝配置Kube-dns
- 安裝配置CoreDNS
- 運維管理
- Master節點高可用
- 服務滾動升級
- 應用日志收集
- 配置最佳實踐
- 集群及應用監控
- 數據持久化問題
- 管理容器的計算資源
- 集群聯邦
- 存儲管理
- GlusterFS
- 使用GlusterFS做持久化存儲
- 使用Heketi作為Kubernetes的持久存儲GlusterFS的external provisioner
- 在OpenShift中使用GlusterFS做持久化存儲
- GlusterD-2.0
- Ceph
- 用Helm托管安裝Ceph集群并提供后端存儲
- 使用Ceph做持久化存儲
- 使用rbd-provisioner提供rbd持久化存儲
- OpenEBS
- 使用OpenEBS做持久化存儲
- Rook
- NFS
- 利用NFS動態提供Kubernetes后端存儲卷
- 集群與應用監控
- Heapster
- 使用Heapster獲取集群和對象的metric數據
- Prometheus
- 使用Prometheus監控kubernetes集群
- Prometheus查詢語言PromQL使用說明
- 使用Vistio監控Istio服務網格中的流量
- 分布式跟蹤
- OpenTracing
- 服務編排管理
- 使用Helm管理Kubernetes應用
- 構建私有Chart倉庫
- 持續集成與發布
- 使用Jenkins進行持續集成與發布
- 使用Drone進行持續集成與發布
- 更新與升級
- 手動升級Kubernetes集群
- 升級dashboard
- 領域應用概覽
- 微服務架構
- 微服務中的服務發現
- 使用Java構建微服務并發布到Kubernetes平臺
- Spring Boot快速開始指南
- Service Mesh 服務網格
- 企業級服務網格架構
- Service Mesh基礎
- Service Mesh技術對比
- 采納和演進
- 定制和集成
- 總結
- Istio
- 安裝并試用Istio service mesh
- 配置請求的路由規則
- 安裝和拓展Istio service mesh
- 集成虛擬機
- Istio中sidecar的注入規范及示例
- 如何參與Istio社區及注意事項
- Istio教程
- Istio免費學習資源匯總
- 深入理解Istio Service Mesh中的Envoy Sidecar注入與流量劫持
- 深入理解Istio Service Mesh中的Envoy Sidecar代理的路由轉發
- Linkerd
- Linkerd 使用指南
- Conduit
- Condiut概覽
- 安裝Conduit
- Envoy
- Envoy的架構與基本術語
- Envoy作為前端代理
- Envoy mesh教程
- SOFAMesh
- SOFAMesh中的Dubbo on x-protocol
- SOFAMosn
- 使用 SOFAMosn 構建 SOFAMesh
- 大數據
- Spark standalone on Kubernetes
- 運行支持Kubernetes原生調度的Spark程序
- Serverless架構
- 理解Serverless
- FaaS-函數即服務
- OpenFaaS快速入門指南
- 邊緣計算
- 人工智能