3、容器与虚拟机的优劣
特性 | 容器 | 虚拟机 |
启动 | 秒级 | 分钟级 |
内存额外损耗 | 无 | 200MB+ |
硬盘使用 | 一般为 MB | 一般为 GB |
性能 | 接近原生 | 弱于 |
系统支持量 | 单机支持上千个容器 | 一般几十个 |
隔离性 | 较差 | 比较好 |
4、docker的架构
docker是一个典型的client-server结构
三、k8s与docker的关系
1、k8s与docker以前是竞争+合作的关系,现在docker已经竞争失败了,那我们就讲讲k8s是怎么用docker的
k8s中最小的调度单位是pod,而一个pod最少包含两个 docker容器,k8s通过kubelet来调用docker
其中Infra容器是使用汇编语言编写的镜像,镜像名为:k8s.gcr.io/pause,解压后大小也只有100-200k,这个容器永远处于“暂停”状态。
容器A、容器B以及容器Infra合起来是一个pod,他们的关系类似于Linux系统里面的进程组的关系,通过Infra共享网络、mount等namespace以及Cgroup
四、k8s的组件架构
官方图:
服务端:
kube-apiserver: API 服务器是 Kubernetes 控制面的组件, 该组件公开了 Kubernetes API。 API 服务器是 Kubernetes 控制面的前端。只有apiserver 才能与存储etcd进行连接通信,其他组件都是通过apiserver与etcd间接通信。
etcd: etcd 是兼具一致性和高可用性的键值数据库,可以作为保存 Kubernetes 所有集群数据的后台数据库。
kube-scheduler: 控制平面组件,负责监视新创建的、未指定运行节点(node)的 Pods,选择节点让 Pod 在上面运行。
kube-controller-manager: 运行控制器进程的控制平面组件。
cloud-controller-manager: 云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。由各个云服务商进行定制提供。
node端:
kube-proxy: kube-proxy 是集群中每个节点上运行的网络代理, 实现 Kubernetes 服务(Service) 概念的一部分。
五、k8s的资源对象
1、资源对象详解
首先从容器出发,可能容器间需要相互协助,所以就有了pod,然后应用需要多副本(一个副本是一个pod),就有了deployment,多副本之间需要有相同的配置文件,就有了configmap。有比较特殊的配置需要加密(例如数据库连接信息),就有了secret。多副本之间的流量需要负载均衡,就有了Service。流量需要有一个统一的入口,并且因为service是4层的且ClusterIP模式只能在集群内部访问,nodePort模式每个服务透出的端口又都是不一样的,所以就需要ingress对象去把相关的服务统一入口,并透出集群。
2、pod创建流程
第一步通过apiserver REST API
创建一个Pod
然后apiserver
接收到数据后将数据写入到etcd
中
由于kube-scheduler
通过apiserver watch API
一直在监听资源的变化,这个时候发现有一个新的Pod
,但是这个时候该Pod
还没和任何Node
节点进行绑定,所以kube-scheduler
就经过一系列复杂的调度策略,选择出一个合适的Node
节点,将该Pod
和该目标Node
进行绑定,当然也会更新到etcd
中去的
这个时候一样的目标Node
节点上的kubelet
通过apiserver watch API
检测到有一个新的Pod
被调度过来了,他就将该Pod
的相关数据传递给后面的容器运行时(container runtime
),比如Docker
,让他们去运行该Pod
而且kubelet
还会通过container runtime
获取Pod
的状态,然后更新到apiserver
中,当然最后也是写入到etcd
中去的。
六、k8s故障排查
流量拓扑图
故障排查图
七、书籍推荐