diff --git a/content/blog/360search-infra-share.md b/content/blog/360search-infra-share.md new file mode 100644 index 0000000..74cd3ee --- /dev/null +++ b/content/blog/360search-infra-share.md @@ -0,0 +1,186 @@ ++++ +title = "360搜索容器云探索与实践" +date = "2018-11-13T14:07:31+02:00" +tags = ["kubernetes","docker","cloud"] +categories = ["qihoo"] +banner = "img/banners/search-cloud.png" +author = "WilliamGuo" +authorLink = "https://wilhelmguo.cn" ++++ + +【编者的话】随着容器化进程的加速，容器编排的需求也越来越强烈。而容器编排也经历了从Kubernetes、Mesos和Swarm三足鼎立到今天的Kubernetes一统江湖的局面。现在越来越多的公司选择基于Kubernetes来构建企业内部的私有云。本次分享将为大家介绍360搜索基于Kubernetes打造私有云的整体架构，以及遇到的一些问题和解决方案，希望可以使大家在打造私有云过程中少走一些弯路。 + +本次主要从以下几个方面介绍360搜索云平台的构建历程： + +- 发展历程 +- 架构设计 +- Wayne平台 +- 踩过的一些坑 +- 发展方向 + +## 发展历程 + +### 发展初衷 +- 快速迭代：提升上线效率，开发自助上线并可以快速回滚。 +- 提高资源利用率：不用类型业务混布，充分利用机器资源。 + +### 发展历史 +360搜索从2016年开始探索基于Kubernetes打造公司私有云平台，由于当时Kuebrnetes对有状态服务支持力度有限以及历史遗留业务容器化难度较大，因此Kubernetes主要负责部署一些无状态的Web服务。 + +从2017年开始Kubernetes逐渐在私有云市场占据了绝对优势，已然成为容器编排的标准。同时Kubernetes对有状态的服务支持逐渐完善，我们开始完全基于Kubernetes打造私有云平台。目前已稳定运行上万台容器。 + + +## 架构设计 + +下图是云平台整体架构 + +![](/img/blog/search-cloud.png?classes=border,shadow) + +### 网络 + +#### Flannel时代 +早期使用的是Flannel VXLAN网络模型，存在转发表项太多的问题。 +![](/img/blog/network1.png?classes=border,shadow) +后面flannel优化，降低了转发表项 +![](/img/blog/network2.png?classes=border,shadow) + +接入方面使用ExternalIP边缘节点的模式，由iptables做nat +![](/img/blog/network3.png?classes=border,shadow) + +后面做了dsr优化，回程数据包不走flannel网卡 +![](/img/blog/network4.png?classes=border,shadow) + +#### Calico时代 +由于集群规模扩张，同时公司基础网络也支持了BGP，所有集群都迁移到了Calico。 +下图是calico的通讯模式，去掉了vxlan造成的overhead +![](/img/blog/network5.png?classes=border,shadow) + +IDC网络模型 +![](/img/blog/network6.png?classes=border,shadow) + +关于calico的一些改造点 + +- 服务器相同as号，方便部署 +- 使用原有默认路由，ToR不向下宣告路由 +- 聚合到27位路由，宣告给ToR +- 通过annotation实现32位路由 + +网络改造具体详见团队同事的文章[容器网络——从CNI到Calico](http://dockone.io/article/2578) + +### 存储 + +由于搜索有状态的业务较多，最早有状态的服务无法迁移，自己维护了一套Gluster集群，支持了很长一段时间业务存储。 +后来公司存储团队提供了Ceph RBD和Cephfs存储服务，有状态的业务逐渐迁移到了Ceph。存储管理自己开发了Robin（即将开源，敬请期待）组件，用于管理RBD的image对象以及Cephfs的路径。 + +### 日志 + +目前我们的日志搜集方式是业务输出日志到std，Docker将std输出存放到日志目录，Kubelet通过软连的方式连接到/var/log/containers目录。 +早期日志是Logstash统一到/var/log/containers目录下搜集，经过处理发送到Kafka，之后业务去Kafka消费或者直接进HDFS。但随着业务日志量的增加，Logstash耗费资源越来越多，日志积压也越来越严重，此时Filebeat功能已经逐渐完善，但缺少了一些解析Kubernetes资源的功能，于是我们自己扩展了一下Filebeat，自己实现了一个Kubernetes Processor，用于增加Kubernetes的相关标签，比如Deployment Name、Pod Name等。同时还做了一些性能优化，使得单机处理能力大幅提升。具体可以参见我之前写过的博客[Filebeat优化实践](https://wilhelmguo.tk/blog/post/william/Filebeat%E4%BC%98%E5%8C%96%E5%AE%9E%E8%B7%B5) + +## Wayne平台（即将开源，敬请期待） + +Kubernetes虽然很强大，但并不是万能的，要打造一个简单易用的云平台仅仅有Kubernetes是远远不够的。比如： + +- Kubernetes配置过于复杂，直接让开发人员配置Kubernetes对象难度太高，而且也比较容易出错 + +- 由于Kubernetes对权限管理并不完善，不同人员分配不同的权限实现比较困难 + +- Kubernetes想要快速回滚到历史版本比较困难，虽然Deployment保留了历史的RS对象，但是很难知道每个版本做了什么更改，想要快速回滚也比较困难。 + +此时，Wayne作为一个私有云平台的统一入口应运而生。 + +### Wayne简介 + +**Wayne**是一个通用的、基于Web的[Kubernetes](https://kubernetes.io)多集群一站式可视化管理平台。内置了丰富多样的功能，满足企业的通用需求，同时插件化的方式可以方便集成定制化功能。 + +Wayne已大规模服务于360搜索，承载了公司绝大部分业务，稳定管理了上万个容器。 + + +### Wayne可以做什么？ + +- 可视化操作：提供直观、简便的方式操作Kubernetes集群，减小学习成本，快速上线业务。 +- 多样的编辑模式：支持图形化编辑，也支持Json、Yaml两种高级定制化编辑模式。 +- 微内核架构：采用可扩展的插件化方式开发，定制化选择特性功能，更方便的集成符合企业需求的新功能。 +- 多集群管理：可以同时管理多个Kubernetes集群，更方便的管理多个集群。 +- 丰富的权限管理：将资源抽象化为部门、项目级别，角色的权限可以更细化的控制，适用于多部门、多项目的统一集中管理。 + +- 多种登录模式：支持企业级LDAP登录、支持OAuth2登录，支持数据库登录多种模式。 + +- 完备的审计：所有操作都会有完整的审计功能，方便追踪操作历史。 + +- 开放平台：支持APIKey开放平台，用户可自主申请相关APIKey并管理自己的项目。 + +- 多层次监控：提供多级别的监控统计信息，实时关注集群的运行状态。 + +### 集成WebShell + +为了方便用户在线查看日志及进入容器调试，Wayne集成了WebShell功能，用户可以查看Pod列表并且可以进入容器进行调试。 + + +## 踩过的一些坑 + +- Pod健康检查正常，但通过边缘节点无法访问到这个节点上的Pod。 + +原因：由于我们之前试用的是Flannel网络，Flannel挂了无法正常启动，会导致这台机器上的服务无法正常访问。 +解决方案：需要监控Falnnel组件的状态，如果异常立即报警。 + +- Deployment滚动更新过程中流量负载均衡异常,会出现丢失请求的情况 + +原因：Pod Terminating过程中，有些机器的Iptable还未刷新，导致部分流量仍然请求到Terminating的Pod上，导致请求出错。详情参见： + +https://github.com/kubernetes/kubernetes/issues/47597 +https://github.com/kubernetes/kubernetes/issues/43576 + +解决方案：利用Kubernetes的preStop特性为每个Pod设置一个退出时间，让每个Pod收到退出信号时时默认等待一段时间再退出。 + +- Kubernetes1.9之前Apiserver挂掉之后Kubernetes Endpoints不更新，导致部分访问失败。 + +原因：Kubernetes1.9之前只要Apiserver启动成功Kubernetes Endpoints便不再更新，需手动维护。 +解决方案： +升级到Kubernetes 1.10版本后设置 --endpoint-reconciler-type = lease +Use an endpoint reconciler (master-count, lease, none) + +- Iptables莫名丢弃syn包 + +``` bash +0xffffffff815a6a0b : nf_hook_slow+0xeb/0x110 [kernel] +0xffffffff815b6bee : ip_output+0xce/0xe0 [kernel] +0xffffffff815b2646 : ip_forward_finish+0x66/0x80 [kernel] +0xffffffff815b29c7 : ip_forward+0x367/0x470 [kernel] +0xffffffff815b062a : ip_rcv_finish+0x8a/0x350 [kernel] +0xffffffff815b0fb6 : ip_rcv+0x2b6/0x410 [kernel] +0xffffffff8156f9e2 : __netif_receive_skb_core+0x582/0x800 [kernel] +0xffffffff8156fc78 : __netif_receive_skb+0x18/0x60 [kernel] +0xffffffff8156fd00 : netif_receive_skb_internal+0x40/0xc0 [kernel] +0xffffffff81570e88 : napi_gro_receive+0xd8/0x130 [kernel] +0xffffffffa0164df6 : ixgbe_clean_rx_irq+0x466/0xa70 [ixgbe] +0xffffffffa01661bb : ixgbe_poll+0x38b/0x840 [ixgbe] +0xffffffff81570510 : net_rx_action+0x170/0x380 [kernel] +0xffffffff8108f2cf : __do_softirq+0xef/0x280 [kernel] +0xffffffff8108f498 : run_ksoftirqd+0x38/0x50 [kernel] +0xffffffff810b927f : smpboot_thread_fn+0x12f/0x180 [kernel] +0xffffffff810b06ff : kthread+0xcf/0xe0 [kernel] +0xffffffff81696958 : ret_from_fork+0x58/0x90 [kernel] +``` +![](/img/blog/network7.png?classes=border,shadow) + +原因:这个是nf_conntrack设计时对性能的权衡，使用rcu锁，导致snat可能获取到重复的local port，然后丢弃报文，上面是内核中一些函数调用链，具体代码不展开了 + +![](/img/blog/network8.png?classes=border,shadow) + +解决方案： +有两种缓解方式 + + 1. 增加local ip数量，降低冲突概率 + 2. snat中local port选择增加随机过程，实际上centos内核模块有这个功能，只是centos7上iptables命令没实现，可以通过修改iptables代码，在netlink调用时加入NF_NAT_RANGE_PROTO_RANDOM_FULLY + +## 未来发展方向 + +- Wayne开源 + +360搜索私有云平台在搭建过程中从很多CNCF项目中收益，本着取之开源，回馈开源的精神，我们决定将Wayne平台开源，并且会持续开发和长期维护。考虑到目前官方Dashboard并不太好用，而且不支持多集群和多租户管理。相信Wayne的开源会给很多人带来收益。 +> 项目地址[https://github.com/Qihoo360/wayne](https://github.com/Qihoo360/wayne) + +- 服务更多业务迁移 + +目前私有云平台服务容器仅有上万个，还有大量业务没有迁移上云，之后会加大力度协助适合的业务迁移到云平台。 diff --git a/content/blog/cncf-case-study-qihoo.md b/content/blog/cncf-case-study-qihoo.md index 6210d85..61d0516 100644 --- a/content/blog/cncf-case-study-qihoo.md +++ b/content/blog/cncf-case-study-qihoo.md @@ -1,9 +1,10 @@ +++ title = "CNCF案例研究：奇虎360" -date = "2015-06-24T13:50:46+02:00" +date = "2019-02-12T18:07:31+02:00" tags = ["cncf"] categories = ["qihoo"] author = "WilliamGuo" +authorLink = "https://wilhelmguo.cn" banner = "img/banners/qihoo-case-study.png" +++ diff --git a/content/blog/docker-exception.md b/content/blog/docker-exception.md new file mode 100644 index 0000000..ed5f459 --- /dev/null +++ b/content/blog/docker-exception.md @@ -0,0 +1,271 @@ ++++ +title = "Docker 异常总结" +date = "2018-12-14T13:07:31+02:00" +tags = ["docker"] +categories = ["docker"] +banner = "img/blog/docker.png" +author = "WilliamGuo" +authorLink = "https://wilhelmguo.cn" ++++ + +提起容器，大家可能首先想到的是 Docker，Docker 已经当之无愧的成为容器界巨头。如果你使用 Kubernetes 作为私有云的解决方案，Docker 也是首选的容器解决方案。虽然 Docker 很优秀，但 Docker 并不是完美的，甚至存在很多问题。下面介绍我们下在生产环境中遇到的关于 Docker 的一些问题及排查过程。避免大家再踩坑。 + +![](/img/blog/docker.png?classes=border,shadow) + +## 异常一 + +`docker ps` 无响应， Node 节点表现为 NotReady。 + +### 运行信息 + +``` bash +$ docker -v +$ Docker version 17.03.2-ce, build f5ec1e2 + +$ docker-containerd -v +$ containerd version 0.2.3 commit:4ab9917febca54791c5f071a9d1f404867857fcc + +$ docker-runc -v +$ runc version 1.0.0-rc2 +$ commit: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe +$ spec: 1.0.0-rc2-dev +``` + +### 启用 Docker Debug 模式 +有两种方法可以启用调试。 建议的方法是在 `daemon.json` 文件中将 `debug` 设置为 `true`。 此方法适用于每个 Docker 平台。 + +1.编辑 `daemon.json` 文件，该文件通常位于 `/etc/docker/` 中。 如果该文件尚不存在，您可能需要创建该文件。 +2.增加以下设置 + +``` json +{ + "debug": true +} +``` +3.向守护程序发送 HUP 信号以使其重新加载其配置。 + +```bash +sudo kill -SIGHUP $(pidof dockerd) +``` + +可以看到 Docker debug 级别的日志： + +``` bash +Dec 14 20:04:45 dockerd[7926]: time="2018-12-14T20:04:45.788669544+08:00" level=debug msg="Calling GET /v1.27/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dpodsandbox%22%3Atrue%7D%7D&limit=0" +Dec 14 20:04:45 dockerd[7926]: time="2018-12-14T20:04:45.790628950+08:00" level=debug msg="Calling GET /v1.27/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dcontainer%22%3Atrue%7D%7D&limit=0" +Dec 14 20:04:46 dockerd[7926]: time="2018-12-14T20:04:46.792531056+08:00" level=debug msg="Calling GET /v1.27/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dpodsandbox%22%3Atrue%7D%7D&limit=0" +Dec 14 20:04:46 dockerd[7926]: time="2018-12-14T20:04:46.794433693+08:00" level=debug msg="Calling GET /v1.27/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dcontainer%22%3Atrue%7D%7D&limit=0" +Dec 14 20:04:47 dockerd[7926]: time="2018-12-14T20:04:47.097363259+08:00" level=debug msg="Calling GET /v1.27/containers/json?filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dpodsandbox%22%3Atrue%7D%7D&limit=0" +Dec 14 20:04:47 dockerd[7926]: time="2018-12-14T20:04:47.098448324+08:00" level=debug msg="Calling GET /v1.27/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dcontainer%22%3Atrue%7D%2C%22status%22%3A%7B%22running%22%3Atrue%7D%7D&limit=0" +Dec 14 20:04:47 dockerd[7926]: +``` +`dockerd`一直在请求 list containers 接口，但是没有响应。 + +### 打印堆栈信息 +``` bash +$ kill -SIGUSR1 $(pidof dockerd) +``` +生成的调试信息可以在以下目录找到： +``` bash +...goroutine stacks written to /var/run/docker/goroutine-stacks-2018-12-02T193336z.log +...daemon datastructure dump written to /var/run/docker/daemon-data-2018-12-02T193336z.log +``` +查看 goroutine-stacks-2018-12-02T193336z.log 文件内容， + +``` bash +goroutine 248 [running]: +github.com/docker/docker/pkg/signal.DumpStacks(0x18fe090, 0xf, 0x0, 0x0, 0x0, 0x0) + /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/pkg/signal/trap.go:82 +0xfc +github.com/docker/docker/daemon.(*Daemon).setupDumpStackTrap.func1(0xc421462de0, 0x18fe090, 0xf, 0xc4203c8200) + /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/daemon/debugtrap_unix.go:19 +0xcb +created by github.com/docker/docker/daemon.(*Daemon).setupDumpStackTrap + /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/daemon/debugtrap_unix.go:32 +0x10a + +goroutine 1 [chan receive, 91274 minutes]: +main.(*DaemonCli).start(0xc42048a840, 0x0, 0x190f560, 0x17, 0xc420488400, 0xc42046c820, 0xc420257320, 0x0, 0x0) + /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/cmd/dockerd/daemon.go:326 +0x183e +main.runDaemon(0x0, 0x190f560, 0x17, 0xc420488400, 0xc42046c820, 0xc420257320, 0x10, 0x0) + /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/cmd/dockerd/docker.go:86 +0xb2 +main.newDaemonCommand.func1(0xc42041f200, 0xc42045df00, 0x0, 0x10, 0x0, 0x0) + /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/cmd/dockerd/docker.go:42 +0x71 +github.com/docker/docker/vendor/github.com/spf13/cobra.(*Command).execute(0xc42041f200, 0xc42000c130, 0x10, 0x11, 0xc42041f200, 0xc42000c130) + /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/vendor/github.com/spf13/cobra/command.go:646 +0x26d +github.com/docker/docker/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc42041f200, 0x16fc5e0, 0xc42046c801, 0xc420484810) + /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/vendor/github.com/spf13/cobra/command.go:742 +0x377 +github.com/docker/docker/vendor/github.com/spf13/cobra.(*Command).Execute(0xc42041f200, 0xc420484810, 0xc420084058) + /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/vendor/github.com/spf13/cobra/command.go:695 +0x2b +main.main() + /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/cmd/dockerd/docker.go:106 +0xe2 + +goroutine 17 [syscall, 91275 minutes, locked to thread]: + +... +``` + +至此，我们可以确定，`containerd` 无响应导致的 `docker ps` 无响应，在堆栈中我们也可以看到调用 `containerd` 无响应是因为加了lock. + +### 查看dmesg +通过 dmesg 查看系统异常信息,发现 `cgroup` 报 OOM 溢出错误。 + +``` bash +[7993043.926831] Memory cgroup out of memory: Kill process 20357 (runc:[2:INIT]) score 970 or sacrifice child +``` + +查看了大部分机器的 dmesg 信息，发现都有 OOM 这个错误，至此我们怀疑是由于某个容器 OOM 导致的 containerd 无响应. + +### 模拟OOM + +既然怀疑是容器 OOM 异常导致的 containerd 无响应，那我们干脆自己创造现场模拟一下。 + +首选我们创建一个 OOM 的部署，通过 nodeSelector 让这个部署调度到指定 Node。 + +``` yaml +apiVersion: extensions/v1beta1 +kind: Deployment +metadata: + labels: + wayne-app: oomtest + wayne-ns: test + app: oomtest + name: oomtest +spec: + selector: + matchLabels: + app: oomtest + template: + metadata: + labels: + wayne-app: oomtest + wayne-ns: test + app: oomtest + spec: + nodeSelector: + kubernetes.io/hostname: test-001 + containers: + - resources: + limits: + memory: 0.2Gi + cpu: '0.2' + requests: + memory: 0.2Gi + cpu: '0.1' + args: + - '-m' + - '10' + - '--vm-bytes' + - 128M + - '--timeout' + - 60s + - '--vm-keep' + image: progrium/stress + name: stress + +``` +发现过了一会 test-001 这台 Node 出现了 `docker ps` 无响应的情况，查看 `dmesg` 以及 `containerd` 的堆栈信息，发现和之前的 Node 出现的异常一致。至此，基本可以确定是某个容器 OOM + 导致的 containerd hung 住。 + +### 原因分析 + +通过查找社区 Issues 及相关 PR，最后发现根本原因是 runc 的bug。 + +使用 `runc start` 或 `runc run` 启动容器时，stub process（runc [2：INIT]）打开一个 `fifo` 进行写入。 它的父 runc 进程 +将打开相同的 fifo 阅读。 通过这种方式，它们可以同步。 + +如果 stub process 在错误的时间退出，那么父 `runc` 进程 +会永远被阻塞。 + +当两个 `runc` 操作相互竞争时会发生这种情况：`runc run / start` 和 `runc delete`。 它也可能由于其他原因而发生， +例如 内核的 OOM killer 可以选择杀死 stub process。 + +### 解决方案： + +通过解决 exec fifo 竞争来解决这个问题。 如果 +在我们打开 fifo 之前 stub process 退出，那么返回一个错误。 + +### 小结 + +`containerd` 官方已经在 v1.0.2 版本合并了这个修改。因此这个问题可以通过升级 Docker 版本解决。我们目前已经将部分机器升级到 Docker 18.06。 已升级的机器暂时未发现类似问题。 + +相关issues： +[https://github.com/containerd/containerd/issues/1882](https://github.com/containerd/containerd/issues/1882) +[https://github.com/containerd/containerd/pull/2048](https://github.com/containerd/containerd/pull/2048) +[https://github.com/opencontainers/runc/pull/1698](https://github.com/opencontainers/runc/pull/1698) + +## 异常二 +Docker 在 Centos 系统下以 direct-lvm 模式运行, 无法启动 + +``` bash +Error starting daemon: error initializing graphdriver: devicemapper: Non existing device docker-thinpool +Dec 14 03:21:03 two-slave-41-135 systemd: docker.service: main process exited, code=exited, status=1/FAILURE +Dec 14 03:21:03 two-slave-41-135 systemd: Failed to start Docker Application Container Engine. +Dec 14 03:21:03 two-slave-41-135 systemd: Dependency failed for kubernetes Kubelet. +Dec 14 03:21:03 two-slave-41-135 systemd: Job kubelet.service/start failed with result 'dependency'. +``` + +### 根本原因 +这个问题发生在使用 devicemapper 存储驱动时Docker试图重用之前使用 LVM thin pool。例如，尝试更改节点上的 Docker 的数据目录时会发生此问题。由于安全措施旨在防止 Docker 因配置问题而意外使用和覆盖 LVM thin pool 中的数据，因此会发生此错误。 + +### 解决方案 +要解决阻止Docker启动的问题，必须删除并重新创建逻辑卷，以便Docker将它们视为新的thin pool。 + +> 警告：这些命令将清除Docker数据目录中的所有现有镜像和卷。 请在执行这些步骤之前备份所有重要数据。 + +1.停止 Docker + +```bash +sudo systemctl stop docker.service +``` +2.删除 Dodcker 目录 + +```bash +sudo rm -rf /var/lib/docker +``` +3.删除已经创建的 thin pool 逻辑卷 + +``` bash +$ sudo lvremove docker/thinpool +Do you really want to remove active logical volume docker/thinpool? [y/n]: y + Logical volume "thinpool" successfully removed +``` +4.创建新的逻辑卷 + +``` bash +lvcreate -L 500g --thin docker/thinpool --poolmetadatasize 256m +``` +> 根据实际磁盘大小调整 thinpool 和 metadata 大小 + +### Docker自动direct-lvm模式配置 + +如果您想要让Docker自动为您配置direct-lvm模式，请继续执行以下步骤。 + +1.编辑`/etc/docker/daemon.json`文件以将`dm.directlvm_device_force = value`从`false`更改为`true`。 例如： + +``` bash +{ + "storage-driver": "devicemapper", + "storage-opts": [ + "dm.directlvm_device_force=true" + ] +} +``` +2.除了删除逻辑卷之外，还要删除docker卷组： + +``` bash +$ sudo vgremove docker +``` +3.启动Dokcer + +``` bash +sudo systemctl start docker.service +``` + +## 总结 + +Docker 虽然是目前最常用的容器解决方案，但它仍旧有很多不足。 + +- Docker 的隔离性比较弱，混布容易导致业务互相影响，可能因为一个服务有问题就会影响其他服务甚至影响整个集群。 +- Docker 自己存在一些 bug， 由于历史原因，很多 bug 无法完全归因于内核或者 Docker，需要 Docker 和内核配合修复。 + +所以如果你使用 Docker 作为容器的解决方案，推荐使用较新稳定版，毕竟新版已经修复了很多 bug，没必要自己再踩一遍坑。较新版 Kubernetes 也已经完整支持新版 Docker，具体可以参考[https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md#external-dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md#external-dependencies) + + diff --git a/content/blog/release1.5.md b/content/blog/release1.5.md index 0ae3a5b..d14d8d0 100644 --- a/content/blog/release1.5.md +++ b/content/blog/release1.5.md @@ -1,10 +1,11 @@ +++ title = "Kubernetes 多集群管理平台 Wayne v1.5.0 版本正式发布(完全代替官方dashbord)" -date = "2019-3-1T13:07:31+02:00" +date = "2019-03-01T13:07:31+02:00" tags = ["kubernetes"] categories = ["wayne"] banner = "img/banners/release1.5.png" author = "WilliamGuo" +authorLink = "https://wilhelmguo.cn" +++ 不负众望，1.5.0版本正式发布 https://github.com/Qihoo360/wayne/releases 本次更新基本涵盖了Kubernetes常用资源管理（可以彻底抛弃官方dashbord啦），并且还增加了service和ingress自动注入注解，更好的支持了公有云。 diff --git a/content/contact.md b/content/contact.md index 89181fa..9d5f979 100644 --- a/content/contact.md +++ b/content/contact.md @@ -18,8 +18,8 @@ Wayne 是由360搜索云平台开发团队设计和开发，主要解决 Kuberne #### 捐赠名单 -捐赠名单默认不会在网站上显示，如果你希望显示，可以 fork [官网项目](https://github.com/Qihoo360/cloud-website)， -在[该页面](https://github.com/Qihoo360/cloud-website/blob/master/content/contact.md)底部添加，完成后发 pull request，网站会不定期更新 +捐赠名单默认不会在网站上显示，如果你希望显示，可以 Fork [官网项目](https://github.com/Qihoo360/cloud-website)， +在[该页面](https://github.com/Qihoo360/cloud-website/blob/master/content/contact.md)底部添加，完成后发 Pull Request，网站会不定期更新 | 日期 | 姓名 | 金额 | 备注 | diff --git a/static/img/banners/search-cloud.png b/static/img/banners/search-cloud.png new file mode 100644 index 0000000..42add15 Binary files /dev/null and b/static/img/banners/search-cloud.png differ diff --git a/static/img/blog/docker.png b/static/img/blog/docker.png new file mode 100644 index 0000000..41065e6 Binary files /dev/null and b/static/img/blog/docker.png differ diff --git a/static/img/blog/network1.png b/static/img/blog/network1.png new file mode 100644 index 0000000..512eda3 Binary files /dev/null and b/static/img/blog/network1.png differ diff --git a/static/img/blog/network2.png b/static/img/blog/network2.png new file mode 100644 index 0000000..abe1362 Binary files /dev/null and b/static/img/blog/network2.png differ diff --git a/static/img/blog/network3.png b/static/img/blog/network3.png new file mode 100644 index 0000000..78d020a Binary files /dev/null and b/static/img/blog/network3.png differ diff --git a/static/img/blog/network4.png b/static/img/blog/network4.png new file mode 100644 index 0000000..2c28c3c Binary files /dev/null and b/static/img/blog/network4.png differ diff --git a/static/img/blog/network5.png b/static/img/blog/network5.png new file mode 100644 index 0000000..717b709 Binary files /dev/null and b/static/img/blog/network5.png differ diff --git a/static/img/blog/network6.png b/static/img/blog/network6.png new file mode 100644 index 0000000..cb05a87 Binary files /dev/null and b/static/img/blog/network6.png differ diff --git a/static/img/blog/network7.png b/static/img/blog/network7.png new file mode 100644 index 0000000..1550fa6 Binary files /dev/null and b/static/img/blog/network7.png differ diff --git a/static/img/blog/network8.png b/static/img/blog/network8.png new file mode 100644 index 0000000..ddc1a69 Binary files /dev/null and b/static/img/blog/network8.png differ diff --git a/static/img/blog/search-cloud.png b/static/img/blog/search-cloud.png new file mode 100644 index 0000000..42add15 Binary files /dev/null and b/static/img/blog/search-cloud.png differ diff --git a/static/img/icon.png b/static/img/icon.png new file mode 100644 index 0000000..4bb00a5 Binary files /dev/null and b/static/img/icon.png differ diff --git a/static/img/logo-small.png b/static/img/logo-small.png deleted file mode 100644 index c6aaa97..0000000 Binary files a/static/img/logo-small.png and /dev/null differ diff --git a/static/img/logo.png b/static/img/logo.png deleted file mode 100644 index 75508b8..0000000 Binary files a/static/img/logo.png and /dev/null differ diff --git a/themes/hugo-universal-theme/layouts/_default/single.html b/themes/hugo-universal-theme/layouts/_default/single.html index 49ea68b..b070d1c 100644 --- a/themes/hugo-universal-theme/layouts/_default/single.html +++ b/themes/hugo-universal-theme/layouts/_default/single.html @@ -24,7 +24,11 @@
-

{{ if .Params.author }}{{ i18n "authorBy" }} {{ .Params.author }} | {{ end }}{{ .Date.Format .Site.Params.date_format }}

+

{{ if .Params.author }}{{ i18n "authorBy" }} + {{ if .Params.authorLink }} + {{ .Params.author }} + {{ else }} + {{ .Params.author }} {{ end }}| {{ end }}{{ .Date.Format .Site.Params.date_format }}

{{ .Content }} diff --git a/themes/hugo-universal-theme/layouts/partials/clients.html b/themes/hugo-universal-theme/layouts/partials/clients.html index a012367..91b92a2 100644 --- a/themes/hugo-universal-theme/layouts/partials/clients.html +++ b/themes/hugo-universal-theme/layouts/partials/clients.html @@ -18,10 +18,10 @@

{{ .Site.Params.clients.title }}

  • {{ if .url }} - {{ .name }} + {{ .name }} {{ else }} - {{ .name }} + {{ .name }} {{ end }}
    • {{ end }} diff --git a/themes/hugo-universal-theme/layouts/partials/footer.html b/themes/hugo-universal-theme/layouts/partials/footer.html index 8ded7dd..5718ff3 100644 --- a/themes/hugo-universal-theme/layouts/partials/footer.html +++ b/themes/hugo-universal-theme/layouts/partials/footer.html @@ -61,19 +61,6 @@

    {{ i18n "contactTitle" }}

    - - {{ if .Site.GoogleAnalytics }} - - {{ end }} - diff --git a/themes/hugo-universal-theme/layouts/partials/head.html b/themes/hugo-universal-theme/layouts/partials/head.html index 55fc8a9..3f31757 100644 --- a/themes/hugo-universal-theme/layouts/partials/head.html +++ b/themes/hugo-universal-theme/layouts/partials/head.html @@ -50,8 +50,8 @@ ` | safeHTML }} - - + + diff --git a/themes/hugo-universal-theme/layouts/partials/scripts.html b/themes/hugo-universal-theme/layouts/partials/scripts.html index 00d9be0..be61426 100644 --- a/themes/hugo-universal-theme/layouts/partials/scripts.html +++ b/themes/hugo-universal-theme/layouts/partials/scripts.html @@ -1,4 +1,19 @@ -{{ template "_internal/google_analytics.html" . }} + + +{{ if .Site.GoogleAnalytics }} + +{{ end }} + diff --git a/themes/hugo-universal-theme/static/css/custom.css b/themes/hugo-universal-theme/static/css/custom.css index 0311119..7baaf30 100644 --- a/themes/hugo-universal-theme/static/css/custom.css +++ b/themes/hugo-universal-theme/static/css/custom.css @@ -9,9 +9,17 @@ min-height: 230px; } +#blog-post #post-content { + font-size: 16px; + line-height: 1.8; +} -/* scaffolding */ -body p { - font-family: Monospaced Number, Chinese Quote, -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, PingFang SC, Hiragino Sans GB, Microsoft YaHei, Helvetica Neue, Helvetica, Arial, sans-serif; +#content p { font-size: 16px; + line-height: 1.8; +} + +#post-content p img { + max-width: 100%; + height: auto; } diff --git a/themes/hugo-universal-theme/static/css/style.blue.css b/themes/hugo-universal-theme/static/css/style.blue.css index 41a1d35..c738447 100644 --- a/themes/hugo-universal-theme/static/css/style.blue.css +++ b/themes/hugo-universal-theme/static/css/style.blue.css @@ -2167,9 +2167,6 @@ fieldset[disabled] .btn-template-primary.active { } #blog-post #post-content { margin-bottom: 20px; - /** custom define **/ - font-size: 16px; - line-height: 1.8; } #blog-post .comment { margin-bottom: 25px;