docker网络 docker集群网络理解 根据容器运行中显示的网卡，使用 docker network ls 查看了对应的docker网络： 10.255/16 ingress overlay swarn 172.21/16 mynets overlay swarn 172.18/16 docker_gwbridge bridge local 其中1、3是默认的，2是手动创建的，当然类型也是有所不同，1、2是overlay，3是bridge 这里来讲解下他们的异同、用处： 首先是1、2 它们的类型都是一样的，就只有默认、自定义的区别，那究竟有什么分别呢？ 默认的 ingress 承担了堆外暴露和负载均衡功能，我们 publish 后即可通过宿主机 ip 端口访问此服务并且负载均衡，而自定义 overlay 是不提供堆外暴露的，及时 publish 也无法通过宿主机 ip 端口访问，需要再增加一个 nginx + ingress 来提供堆外服务 自定义的 overlay 主要是承担服务之间的通信，当然 ingress 网络类型一样，也是有此功能的，但不侧重，再就是 自定义的可以提供更加细粒度的控制，比如不同服务之间分配不同的 overlay 来隔离 docker_gwbridge 主要提供了在不同宿主机上容器与容器、同一宿主机上容器与宿主机、容器与外部的访问，也就是除了同一宿主机下容器互访之外的其他网络需求，同一宿主机容器之间可以通过 overlay 直接互访 网络走向 请求是如何通过任意节点最终到达目的服务器的呢？ 包括 docker 自带的负载均衡如何转发？大概是如下流程： 请求先到宿主机nat表，DNAT请求到本地172.18.0.2网络 通过本地路由到地址为172.18.0.1的网络docker_gwbridge，每个宿主机本地都有一个172.18.0.1地址 docker_gwbridge网关找到172.18.0.2为ingress-sbox ingress-sbox接受请求后在mangle表的PREROUTING链打标记 mangle表的INPUT链根据标记转发到服务（service）的虚拟ip地址（实际上所有服务的虚拟ip地址都在ingress-sbox上配置） 请求准备发送到此虚拟ip，当到达nat表POSTROUTING链的时候被拦截，执行源地址转换，规则是所有目的地址是集群网段都转发到本机的ipvs虚拟地址 ingress-sbox的ipvs根据mangle的标记，再把请求发送到集群内指定服务容器的ip 参考文档 https://blog.csdn.net/weixin_36171533/article/details/81842036 https://www.jianshu.com/p/c83a9173459f https://www.cnblogs.com/www1707/p/10872748.html libnetwork 是 docker 容器网络库，最核心的内容是其定义的 Container Network Model (CNM)，这个模型对容器网络进行了抽象，由以下三类组件组成： Sandbox：Sandbox 是容器的网络栈，包含容器的 interface、路由表和 DNS 设置。 Linux Network Namespace 是 Sandbox 的标准实现。Sandbox 可以包含来自不同 Network 的 Endpoint Endpoint：Endpoint 的作用是将 Sandbox 接入 Network。Endpoint 的典型实现是 veth pair，后面我们会举例。一个 Endpoint 只能属于一个网络，也只能属于一个 Sandbox Network：Network 包含一组 Endpoint，同一 Network 的 Endpoint 可以直接通信。Network 的实现可以是 Linux Bridge、VLAN 等

docker集群问题之ip地址不足 异常问题 docker集群网络地址不足，无法启动新的容器，可以按照如下步骤处理： 创建新的集群网络 docker network create -d overlay --attachable --subnet 172.21.0.0/16 mynets 服务加入此网络 docker service update --network-add=mynets service_name 服务删除之前的网络 docker service update --network-rm=mynet service_name 注：加入和删除也可以在服务为0时操作，另添加的网络不要跟现有的网络冲突

docker进程前台和后台的选择 自定义的进程 首先我们明确一个点，那就是 容器 要一直能够运行，需要一个进程始终运行，那么如下这种命令肯定是不行的: CMD service mysql start 因为这个指令它在终端执行就结束了，它最终确实调用了 mysql 启动，但是它本身无法一直处于运行状态，所以这种指令构建的容器运行一会儿就会停止 解决方法 根据上面的问题，我们可以改善指令如下几种: 多执行一个 tail 日志的操作，这样的话整个指令不会结束 CMD service mysql start && tail -F /var/log/mysql/error.log 使用 mysqld_safe 来启动 CMD /usr/bin/mysqld_safe 这是mysql服务的前台启动方式，它也能够一直保持在前台运行状态 3. 使用自定义的脚本 CMD /start.sh 注意自定义脚本也要符合要求，不能够立即退出 前台or后台 其实区别在前面两种中已经展示了，在正常使用没有太多的区别，但是有一些情况下使用前台是比较好的，比如 启动一个 jar 程序或者一个 python 脚本 不过这里又出现了一个问题，如何查看程序的日志？ 即使我们已经把 jar 程序 或者 python 脚本的日志输出到了定义的目录中，但是程序难免会出现异常，没有捕获到的异常往往在前台显示，所以应该如何看呢？ 这个时候使用 docker exec -it container_id /bin/bash 是不行的，它会进入一个新的终端中，完全看不到启动容器前台的日志，所以需要使用 docker logs -f container_id 由它来打印标准输出的日志

Truenas Jail和容器的选择 0x1 问题背景 考虑使用这些的原因是NFS的问题，在Truenas Core某个时间后，NFS的挂载经常报IO错误，但是文件实际上在NAS上是可以正常读写的，详细的排查见其他帖子，并且这个问题最终也没有结论。但规避方法是，采用虚拟机、jail、容器等方式拆分整个NFS，使得每个NFS server只需要负责一部分的文件，减小互相影响 0x2 优劣势 虚拟机：占用资源比较多，如果后续需要多个NFS或者其他服务，那么势必会占用一部分当前的 zfs arc 的空间 jail：这个是freebds的一个虚拟化工具，在性能、功能上貌似比较强大，本想尝试一下，但是资料太小，并且到底能否是否NFS server也没有找到可靠的资料 容器：基本上平衡了性能，功能的问题，最终还是选择使用它了 0x3 Truenas容器 查询了一些资料，发现Truenas Core是基于freebds的类unix系统，不支持docker或者其他容器，如果要使用容器则需要换成Truenas Scale，这是前几年基于Linux发行的版本，相对于Core版本有更多的应用扩展了，还好我们目前没有在Truenas上有过多的应用，所以按照升级方案处理即可 在升级后可以看到Truenas Scale是自带容器的，不过貌似是精简版的k3s，更多详细的功能参考其他文档

docker swarm架构更改 当前架构 目前整个docker swarm架构是: 节点数量： 3管理节点，4工作节点 keepalived 自动配置 VIP 到任意管理节点 WEB 服务由 3副本 NGINX （HOST模式）代理其服务名 使用 VIP 对外提供服务, 只访问到此 NGINX 当 VIP 管理节点故障时候，由 keepalived 切换 VIP 到其他管理节点 问题现状 上面的架构实现了一部分的高可用、也存在一定的问题： docker swarm 高可用，挂1-2个管理、工作节点能够保证环境正常 比较依赖于VIP和管理节点的联动，VIP+keepalived+docker swarn全部集中在一起 存在一定的网络问题，比如bind服务容器化后，VIP所在的机器中的容器可能无法访问到VIP地址提供的bind解析，可见之前分析的dns问题 目前的问题在于各个部件耦合的太紧，当发生故障的时候，keepalived、nginx、VIP等都需要切换，还要考虑VIP切换到了哪个nginx节点，这样维护比较麻烦。所以希望解耦服务之间的关系，让每个服务只关心自己的部分，并且解决 dns 解析的 nat 问题 架构变更 架构的变更需要考虑服务解耦，并且每个部分实现一定的高可用： 分离出当前的7层nginx，变成4层代理，部署到2-3个节点到其他物理机上，VIP部署在此nginx，stream代理所有的docker节点，实现高可用 nginx、bind等服务改成replicate模式，副本1，设置故障自动恢复 （可选）nginx可以考虑替换为 treafik等微服务网关，可以实现7层会话保持以及自动发现、failover等 tomcat镜像设置健康检查，使得多副本情况下，只是服务挂了也可以被docker正确的识别到，不再让ipvs转发到此节点 HEALTHCHECK --interval=5s --timeout=3s --retries=3 \ CMD curl -fs http://localhost/ || exit 1 经过以上调整后多副本的服务高可用： 如果某个副本宕机，可以马上识别到并且移除，时间应该在几秒内 如果是副本内服务挂掉，健康检测可以在20秒内判断，并且不再转发 如果docker物理机宕机，重要容器failover，nginx不再转发到此节点