容器 & k8s

Jun 27, 2021 · 1944 words · 4 minute read

容器 🔗

docker 架构，镜像，容器，网络，存储。

容器规范 OCI。 runtime （lxc， runc，rkt），镜像格式。

集装箱运输货物，docker 运输移植软件。

镜像，容器层（可读可写），镜像层（只读）。

docker run -it ubuntu。以交互模式进入容器并打开终端。

-d 后台运行。

容器技术历史 🔗

1979 年 chroot 设置进程访问的根目录

2006 年 google 给 kernel 提供 Control Groups

2008 年 LXC 第一个容器管理方案

2015 年 google 提供 libcontainer

2013 年容器管理产品 docker

docker 简化服务的管理，类似 systemd, supervisor; 但更加重要的镜像技术。

docker run hello-world
 1. The Docker client -> Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.(arm64v8)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

docker 的实现 🔗

unionFS, 分层镜像实现。unionFS可以把文件系统上的多个目录内容联合挂载到同一个目录下，而目录的物理位置是分开的。

namespace

cgroup

docker 常见命令 🔗

将镜像打包为 tar 文件 🔗

image -- docker save --> tar 包

tar 包 -- docker load --> image

dockerfile 🔗

基于容器生成镜像 🔗

docker commit -m "create new image" -a "brett" container_id newimage:v1.0

执行容器内部的脚本 🔗

docker exec container_name bash -c 'bash /root/start.sh'

基于镜像启动容器 🔗

docker run -itd --name="container name" --net=host -v /home/dist/:/root/server/web/public image_name

容器运行时 containerdy 🔗

		docker client
		docker daemon
		containerd
	containerd-shim   containerd-shim
	runc(OCI标准)	          runc

runc （OCI 标准） 🔗

OCI（Open Container Initiative）即开放的容器运行时规范， (runtime-spec)[https://github.com/opencontainers/runtime-spec/blob/main/runtime.md]：容器的生命周期管理; (image-spec)[https://github.com/opencontainers/image-spec/blob/main/spec.md]: 镜像的生命周期管理。
实现 OCI 标准的容器运行时有 runc，kata
# runc 用来创建和运行容器，containerd 作为常驻进程用来管理容器
docker start -> containerd api -> containerd shim -> runc create, init, start
opencontainers/runc/create.go#var createCommand = cli.Command{...}

k8s 架构 🔗

api server
scheduler
controler
kubelet
- pod 管理
- 容器健康检查 LivenessProbe 与 ReadinessProbe
- 容器监控通过 cAdvisor 获取节点和容器的数据
proxy
pod （进程组）
- 打开容器之间的隔离性，两个方向网络和存储来通信。
  - Infra container 小容器来共享整个 Pod 的 Network Namespace, 直接使用 localhost 进行通信。
  - 宿主机上的目录 mount 到 pod 的容积里的文件目录下，实现读写文件通信。
- 一组管理关系紧密的容器（进程），与业务容器需要的 side car 辅助容积（日志收集，service mesh，应用监控）
- 容器不只 containerd，k8s 需要基于 container 做一步抽象 container runtime interfz
- 设计模式本质：解耦复用
service
- 一个 svc 是一个微服务，也是一组 prod，通过 label robin 实现 IP 负载均衡
volume

创建 pod 的主要流程 🔗

client 提交 pod 的 yaml 配置文件到 k8s-apiserver
apiserver 通知给 controller-manager 创建一个资源对象
controller-manager 通过 apiserver 将 pod 的配置信息存储在 etcd 中
k8s-scheduler 检测到 pod 信息开始调度，选择合适的节点，将 pod 的资源配置发到节点上的 kubelet 组件
kubelet 根据资源配置单运行 pod，将 pod 的运行信息返回给 scheduler, 存储到 etcd 中

operator

请求访问 pod 的流程 🔗

hostNetwork：占用特定宿主机上的特定端口。 hostPort：将容器的端口与 node 上的端口做映射

网络

workload 类型， statefulset 🔗

pv, pvc, 动态 pv 的实现 🔗

实操 🔗

安装命令行工具：brew install kubernetes-cli

安装 k8s： brew cask instsall minikube

安装完 minikube 后，minikube start 启动一个 k8s 集群。

$ minikube start
// 在macos arch上error。

解决办法：
$ docker pull kicbase/stable:v0.0.34
$ minikube start --vm-driver=docker --base-image="kicbase/stable:v0.0.34" --image-mirror-country='cn' --image-repository='registry.cn-hangzhou.aliyuncs.com/google_containers' --kubernetes-version=v1.23.8

https://github.com/kubernetes/minikube/issues/14477

minikube status 查看启动情况。

$ minikube dashboard

dashboard启动不了...

$ minikube dashboard --url --alsologtostderr -v=1

I1007 17:53:29.191813   80782 dashboard.go:212] http://127.0.0.1:56602/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ response: <nil> &{Status:503 Service Unavailable StatusCode:503 Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Audit-Id:[88044732-eedc-4974-bb88-f81b1ff242c7] Cache-Control:[no-cache, private] Content-Length:[182] Content-Type:[application/json] Date:[Fri, 07 Oct 2022 09:53:29 GMT]] Body:0x14000113000 ContentLength:182 TransferEncoding:[] Close:false Uncompressed:false Trailer:map[] Request:0x14000daff00 TLS:<nil>}

$ minikube dashboard --url

$ curl -L https://git.io/getLatestIstio | sh -

$ export PATH=$PWD/bin:$PATH
将istioctl命令行工具的路径加入path中。

安装 Helm（k8s 下的包管理工具）， brew install Kubernetes-helm

基于 helm 安装 istio。

访问者模式 🔗

kubectl 里有使用。


type Visitor interface {
	Visit(VisitorFunc) error
}

type VisitorFunc func(*Info, error) error

type VisitorList []Visitor

// Visit implements Visitor
func (l VisitorList) Visit(fn VisitorFunc) error {
	for i := range l {
		if err := l[i].Visit(fn); err != nil {
			return err
		}
	}
	return nil
}

type Visitor interface {
	Visit(VisitorFunc) error
}
type VisitorFunc func() error

type VisitorList []Vistor

func (l VisitorLList)Visit(fn VisitorFunc) error {
	for i := range l {
		if err := l[i].Visit(func() error {
			fmt.Println("in visitorlist before fn")
			fn()
			fmt.Println("in visitorlist after fn")
		}); err != nil {
			return err
		}
	}
	return nil
}

type Visitor1 struct {
}

type (v Visitor1) Visit(fn VisitorFunc) error {
	fmt.Println("in visitor1 before fn")
	fn()
	fmt.Println("in visitor1 after fn")
}

type Visitor2 struct {
	visitor Visitor
}
func (v Visitor2) Visit(fn VisitorFunc) error {
	v.visitor.Visit(func() error{
		fmt.Println("in visitor2 before fn")
		fn()
		fmt.Println("in visitor2 after fn")
		return nil
	})
	return nil
}

type Visitor3 struct {
	visitor Visitor
}

func (v Visitor3) Visit(fn VisitorFunc) error {
	v.visitor.Visit(func() error{
		fmt.Println("in visitor3 before fn")
		fn()
		fmt.Println("in visitor3 after fn")
		return nil
	})
	return nil
}

func main() {
	var visitor Visitor
	var visitors []Visitor

	visitor = Visitor1{}
	visitors = append(visitors, visitor)
	visitor = Visitor2{VisitorList(visitors)}
	visitor = Visitor3{visitor}

	visitor.Visit(func() error{
		fmt.Println("In visitfunc")
		return nil
	})
}

/*
in visitor1 before fn
in visitorlist before fn
in visitor2 before fn
in visitor3 before fn
in visistfunc
in  visitor3 after fn
in visitor2 after fn
in visitorlist after fn
in visitor1 after fn
*/

微服务与 service mesh 🔗

微服务内部有分布式环境下的通用功能：熔断策略、负载均衡、服务发现、认证和授权、quota 限制、trace 和监控等等

这种微服务存在的问题：

虽然有现成的框架做了这些事情，但在也需要业务去配置和管理框架
这些框架 lib 或者 sdk 缺业务语言时，很难融入或者需要开发对应语言的包来融入微服务内部
框架升级，对业务不透明，需要业务自行升级

sidecar 单边模式代理模式。同一个微服务的代理进程 service mesh 互通，与其他微服务的 service mesh 也通信，所以单看代理进程像网一样，所以叫 service mesh。

laas 🔗

虚拟化架构：vmware ESXi Xen 架构（Xen 内核管理 CPU 和 MEM，Deamon 虚拟机管理 net，disk） KVM 架构（KVM 内核管理 CPU 和 MEM， QEMU 管理 net，disk，虚拟机进程调度）

cloud