1 ) 代码
package main
import (
"github.com/gorilla/mux"
"log"
"net/http"
)
func about(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("This is a small app for kubernetes...\n"))
}
func main() {
r := mux.NewRouter()
r.HandleFunc("/", about)
log.Fatal(http.ListenAndServe("0.0.0.0:2580", r))
}
使用 go build 命令编译这个程序,产生 app 可执行文件
这是一个普通的可执行文件,它在操作系统里运行,会依赖系统里的库文件
# ldd app
linux-vdso.so.1 => (0x00007ffd1f7a3000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f554fd4a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f554f97d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f554ff66000)
2 ) “笼子”
为了让这个程序不依赖于操作系统自身的库文件,我们需要制作容器镜像,即隔离的运行环境, Dockerfile 是制作容器镜像的“菜谱”
我们的菜谱就只有两个步骤,下载一个 centos 的基础镜像,把 app 这个可执行文件放到镜像中 /usr/local/bin 目录中去
FROM centos
ADD app /usr/local/bin
3 ) 地址
registry.cn-hangzhou.aliyuncs.com/kube-easy/app:latest
1 ) 入口
2 ) 双向数字证书验证
3 )KubeConfig 文件
登录集群管理控制台,我们可以拿到 KubeConfig 文件
这个文件包括了客户端证书,集群 CA 证书,以及其他
证书使用 base64 编码,所以我们可以使用base64 工具解码证书,并使用 openssl 查看证书文本。
首先,客户端证书的签发者 CN 是集群 id c0256a3b8e4b948bb9c21e66b0e-1d9a72
而证书本身的 CN 是子账号 252771643302762862
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 787224 (0xc0318)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
Validity
Not Before: Nov 29 06:03:00 2018 GMT
Not After : Nov 28 06:08:39 2021 GMT
Subject: O=system:users, OU=, CN=252771643302762862
其次,只有在 API Server 信任客户端 CA 证书的情况下,上边的客户端证书
才能通过 API Server 的验证
kube-apiserver 进程通过 client-ca-file 这个参数指定其信任的客户端 CA 证书,其指定的证书是 /etc/kubernetes/pki/apiserver-ca.crt
这个文件实际上包含了两张客户端 CA 证书,其中一张和集群管控有关系
这里不做解释,另外一张如下,它的 CN 与客户端证书的签发者 CN 一致
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 787224 (0xc0318)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
Validity
Not Before: Nov 29 06:03:00 2018 GMT
Not After : Nov 28 06:08:39 2021 GMT
Subject: O=system:users, OU=, CN=252771643302762862
再 次,API Server 使 用 的 证 书, 由 kube-apiserver 的 参 数 tls-cert-file决定
这个参数指向证书 /etc/kubernetes/pki/apiserver.crt。这个证书的CN 是 kube-apiserver
签 发 者 是 c0256a3b8e4b948bb9c21e66b0e-1d9a72,即集群 CA 证书
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2184578451551960857 (0x1e512e86fcba3f19)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
Validity
Not Before: Nov 29 03:59:00 2018 GMT
Not After : Nov 29 04:14:23 2019 GMT
Subject: CN=kube-apiserver
最后,客户端需要验证上边这张 API Server 的证书,因而 KubeConfig 文件里包含了其签发者,即集群 CA 证书
对比集群 CA 证书和客户端 CA 证书,发现两张证书完全一样,这符合我们的预期
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 786974 (0xc021e)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=CN, ST=ZheJiang, L=HangZhou, O=Alibaba, OU=ACS, CN=root
Validity
Not Before: Nov 29 03:59:00 2018 GMT
Not After : Nov 24 04:04:00 2038 GMT
Subject: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
4 )访问
理解了原理之后,我们可以做一个简单的测试
我们以证书作为参数,使用 curl访问 api server,并得到预期结果
# curl --cert ./client.crt --cacert ./ca.crt --key ./client.key https://xx.xx.xx.xxx:6443/api/
{
"kind": "APIVersions",
"versions": [
"v1"
],
"serverAddressByClientCIDRs": [
{
"clientCIDR": "0.0.0.0/0",
"serverAddress": "192.168.0.222:6443"
}
]
}
1 ) 两种节点,一种任务
2 ) 择优而居
3 ) Pod 配置
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "app"
},
"spec": {
"containers": [
{
"name": "app",
"image": "registry.cn-hangzhou.aliyuncs.com/kube-easy/app:latest",
"command": [
"app"
],
"ports": [
{
"containerPort": 2580
}
]
}
]
}
}
4 ) 日志级别
集群调度算法被实现为运行在 master 节点上的系统组件,这一点和 api server类似
其对应的进程名是 kube-scheduler。kube-scheduler 支持多个级别的日志输出
但社区并没有提供详细的日志级别说明文档。查看调度算法对节点进行筛选、打分的过程
我们需要把日志级别提高到 10,即加入参数 --v=10
kube-scheduler --address=127.0.0.1 --kubeconfig=/etc/kubernetes/scheduler.conf --leader-elect=true --v=10
5 ) 创建 Pod
使用 curl,以证书和 pod 配置文件等作为参数,通过 POST 请求访问 api server 的接口
我们可以在集群里创建对应的 pod
# curl -X POST -H 'Content-Type: application/json;charset=utf-8' --cert ./
client.crt --cacert ./ca.crt --key
./client.key https://47.110.197.238:6443/api/v1/namespaces/default/pods -d@
app.json
6 ) 预选
7 ) 优选
这两种方式,一种倾向于选出资源使用率较低的节点,第二种希望选出两种资源使用比例接近的节点
这两种方式有一些矛盾,最终依靠一定的权重来平衡这两个因素
除了资源之外,优选算法会考虑其他一些因素
这是保证高可用的一种策略
8 ) 得分