Docker 常用模式
docker、containerd、docker-shim、runC之间的关系
- docker：docker本身而言包括了docker client和dockerd，dockerd实属是对容器相关操作的api的最上层封装，直接面向操作用户；
- containerd：dockerd实际真实调用的还是containerd的api接口(rpc方式实现)，containerd是dockerd和runC之间的一个中间交流组件，理论上，不运行dockerd，也能够直接通过containerd来管理容器。
向上为Docker daemon提供gRPC接口，使得Docker Daemon屏蔽下面的结构变化，确保原有接口向下兼容。向下通过containerd-shim结合runC，使得引擎可以独立升级。 - docker-shim：真实运行容器的载体，每启动一个容器都会起一个新的docker-shim的进程。它通过指定三个参数：容器ID、bundle目录(containerd对应某个容器生成目录)，运行时二进制(默认是runC)，来调用runC的api创建一个容器。
- runC：运行容器的命令行工具，根据OCI的标准来创建和运行容器。Docker默认提供了docker-runc实现，事实上，通过containerd的封装，可以在Docker Daemon启动的时候指定runc的实现。
可以通过docker inspec <docker-id>|grep Pid找到docker进程的Pid，然后通过ps查看它的父进程，然后再pstree <父进程>就可以看出它的全部进程结构。
Deployment
Service
Daemonset
这种模式就是确保在每个k8s的node节点上创建一个pod实例，有且仅有一个实例。当node被添加到集群中，Pod也被添加上去。当node被从集群移除，这些Pod会被垃圾回收。删除一个DaemonSet将会清理它创建的Pod。
DaemonSet 的典型应用场景有：
- 在集群的每个节点上运行存储 Daemon，比如 glusterd 或 ceph。
- 在每个节点上运行日志收集 Daemon，比如 flunentd 或 logstash。
- 在每个节点上运行监控 Daemon，比如 Prometheus Node Exporter 或 collectd。
其实 Kubernetes 自己就在用 DaemonSet 运行系统组件。执行如下命令：
kubectl get daemonset --namespace=kube-system
kubectl get pods --namespace=kube-system -o wide
可以看到flannel, kube-proxy等以daemonset形式存在的资源
Daemonset对应的属性例如label,镜像如果更新那么需要更新pod. DaemonSet目前有两种升级策略，可以通过.spec.updateStrategy.type指定：
OnDelete: 该策略表示当更新了DaemonSet的模板后，只有手动删除旧的DaemonSet Pod才会创建新的DaemonSet Pod
RollingUpdate： 该策略表示当更新DaemonSet模板后会自动删除旧的DaemonSet Pod并创建新的DaemonSetPod
sidecar 挎斗模式
将应用程序的组件部署到单独的进程或容器中，以提供隔离和封装。 使用此模式还可以使用异构组件和技术来构建应用程序。
此模式之所以称作“挎斗”(Sidecar)，是因为它类似于三轮摩托车上的挎斗。 在此模式中，挎斗附加到父应用程序，为应用程序提供支持性功能。 此外，挎斗与父应用程序具有相同的生命周期：与父应用程序一起创建，一起停用。 挎斗模式有时也称为搭档模式，这是一种分解模式。
挎斗服务不一定要属于应用程序的一部分，而只是与应用程序相连接。 不管它位于哪个位置，父应用程序都会跟随。挎斗是连同主应用程序一起部署的支持性进程或服务。 以三轮摩托车为例，挎斗附加在一辆三轮摩托车上，每辆三轮摩托车有自身的挎斗。 同样，挎斗服务与其父应用程序具有相同的生命周期。 对于应用程序的每个实例，都会部署一个挎斗实例，并连同应用程序实例一起托管该挎斗实例。
使用挎斗模式的好处包括：
-
在运行时环境和编程语言方面，挎斗与其主应用程序相互独立，因此，无需为每种语言开发一个挎斗。
-
挎斗可以访问主应用程序所能访问的资源。 例如，一个挎斗可以监视该挎斗和主应用程序使用的系统资源。
-
挎斗与主应用程序保持密切的距离，因此两者之间的通信不存在明显的延迟。
-
即使是对于不提供扩展性机制的应用程序，也仍可以使用挎斗来扩展功能，只需在主应用程序所用的同一主机或子容器中，将挎斗附加为自身的进程即可。
挎斗模式通常与容器一起使用，因而称作挎斗容器或搭档容器。
问题和注意事项
- 请考虑部署服务、进程或容器时所用的部署和打包格式。 容器特别适合用于挎斗模式。
- 在设计挎斗服务时，请慎重决定进程间通信机制。 除非达不到性能要求，否则请尽量使用不区分语言或框架的技术。
- 在将功能放入挎斗之前，请考虑该功能是作为独立的服务还是更传统的守护程序运行更有利。
- 此外，请考虑是否能够以库的形式或使用传统扩展机制实现功能。 特定于语言的库可能提供更深度的集成和更少的网络开销。
何时使用此模式
在以下情况下使用此模式：
- 主应用程序使用一组异类语言和框架。 使用不同框架以不同语言编写的应用程序可以使用挎斗服务中的某个组件。
- 某个组件由远程团队或不同的组织拥有。
- 某个组件或功能必须共置在应用程序所在的同一台主机上
- 希望某个服务与主应用程序具有相同的整体生命周期，但同时又能独立更新该服务。
- 需要精细控制特定资源或组件的资源限制。 例如，想要限制特定组件使用的内存量。 可将组件部署为挎斗，然后独立于主应用程序管理内存用量。
此模式可能不适用于以下情况：
- 当进程间通信需要优化时。 父应用程序与挎斗服务之间的通信会产生一定的开销，执行调用时存在明显的延迟。频繁通信的接口可能无法接受这种弊端。
- 在某些小型应用程序中，为每个实例部署挎斗服务所产生的资源开销会抵消隔离所带来的优势。
- 当服务需要以不同于或独立于主应用程序的方式缩放时。 如果存在这种情况，将功能部署为独立的服务可能更好。
示例
挎斗模式适用于许多方案。 一些常见示例：
- 基础结构 API。 基础结构开发团队创建了一个连同每个应用程序一起部署的服务，而不是特定于语言的客户端库，来访问基础结构。 该服务作为挎斗加载，为基础结构服务（包括日志记录、环境数据、配置存储、发现、运行状况检查和监视程序服务）提供一个公用层。 挎斗还监视父应用程序的主机环境和进程（或容器），并将信息记录到集中式服务。
- 管理 NGINX/HAProxy。 将 NGINX 与用于监视环境状态的挎斗服务一起部署，然后，在需要更改状态时更新 NGINX 配置文件并回收进程。
- 代表挎斗。 将代表服务部署为挎斗。 应用程序通过代表发出调用，后者可处理日志记录、路由、断路、和其他连接相关功能。
- 卸载代理。 将 NGINX 代理放在 node.js 服务实例的前面，以便为服务提供静态文件内容
Docker容器启动很慢的原因
- 查看CPU、内存、硬盘存储空间是否足够
- 查看网络是否通畅：镜像仓库，DNS解析，默认路由是否正常
- 容器本身的资源配置过低
