K8s Basic

importance

date

May 23, 2024

slug

K8s Basic

status

Published

容器就是一个进程，由Linux Namespace、Cgroups与rootfs三种技术构建出来的隔离环境。

docker并不是K8s的核心，k8s可以随意替换容器运行时，只要其符合接口规范

google的borg项目

使用minikube创建一个Deployment，开放8080端口作为serive

将deployment扩展到4个replicas

通过describe可以查看service的信息

Endpoints的确出现了4个不同的IP。

可以使用 curl 、节点的 IP 和外部暴露的端口测试应用程序是否已暴露在集群外部。

每一次执行curl命令可以得到不同的结果，意味着service可能依据一定的负载均衡的规则将访问转发到不同的pod。

为了验证我的猜测，用一个小的python脚本，对curl $(minikube ip):$NODE_PORT 执行3K次，并统计结果。

可以看到，这四个pod被执行的次数几乎相同，只有随机数的差异，这说明k8s默认的负载均衡策略就是随机。

可以通过set image命令将pod进行更新

通过不断watch pods，发现如果新的pod没有创建完成，那么久的pod就不会终止。知道所有新的pod都正常运行，旧的pod才会停止并最终删除。

使用rollback 可以回滚到上一次的版本

用minikube 可以创建多个node

可以看到，minikube创建了3个虚拟的node，我猜测如果我创建多个pod，那么pod应该会平均分到每个node上。

因此我创建了6个pod，都是webapp的复制。

运行这个配置文件，生成一个my-webapp的deployment。然后在通过 kubectl get pods -o wide 查看pod在所有node上的分布。果然，6个pod均匀地分配到了3个机器上。并且相同node上的pod，其子网段相同。

同样的，执行3k次curl，统计pod被访问的分布情况。

可以看到，每个node都得到相同概率的访问，每个pod也得到了相同概率的访问。

添加ingress，使得可以从外部访问service。

修改 /etc/hosts 文件，添加上对应的host

访问http://webapp.service/ 网站，可以看到成功访问了容器！流量从 ingress 👉 service 👉 pod

不断curl这个地址，可以看到，每次访问都可能发生在不同的webapp的pod上

deployment的pods是无状态的，意味着重启或者调度这些pods，新的pods和旧的pods没有关系，而StatefulSet用于唯一标识一个pod，即使pods重启之后，也保证是原本的pods。