云计算深度实践者。《每天5分钟玩转OpenStack》《每天5分钟玩转Docker容器技术》作者。
本节详细分析两个 k8s 自己的 DaemonSet:kube-flannel-ds 和 kube-proxy 。
本节介绍 DaemonSet 的几个典型应用场景。
本节讨论如何用 label 控制 pod 在哪个 node 上运行。
今天我们讨论 Kubernetes 如何 Failover。
本节讨论如何在线增加和减少 Pod 的副本数。
读懂 Deployment 的 YAML 文件是必须要掌握的技能。
命令 vs 配置文件
从本章开始,我们将通过实践深入学习 Kubernetes 的各种特性。作为容器编排引擎,最重要也是最基本的功能当然是运行容器化应用,这就是本章的内容。
为了帮助大家更好地理解 Kubernetes 架构,我们部署一个应用来演示各个组件之间是如何协作的。
上一节我们讨论了 Kubernetes 架构 Master 上运行的服务,本节讨论 Node 节点。
Kubernetes Cluster 由 Master 和 Node 组成,节点上运行着若干 Kubernetes 服务。
上节我们通过 kubeadm 在 k8s-master 上部署了 Kubernetes,本节安装 Pod 网络并添加 k8s-node1 和 k8s-node2,完成集群部署。
我们将部署三个节点的 Kubernetes Cluster。
在实践之前,必须先学习 Kubernetes 的几个重要概念,它们是组成 Kubernetes 集群的基石。
本节带领大家快速体验 k8s 的核心功能:应用部署、访问、Scale Up/Down 以及滚动更新。
我们会在最短时间内搭建起一个可用系统。
为什么要学习 Kubernetes?以及如何学?
本节告诉你 stack 有哪些的优势。
stack 是 service 应用高效和可靠的部署方式。
在下面的例子中,我们会部署一个 WordPress 应用,WordPress 是流行的开源博客系统。 我们将创建一个 MySQL service,将密码保存到 secret 中。我们还会创建一个 WordPress service,它将使用 secret 连接 MySQL。
我们可以用 secret 管理任何敏感数据。这些敏感数据是容器在运行时需要的,同时我们不又想将这些数据保存到镜像中。 secret 可用于管理: 用户名和密码。 TLS 证书。 SSH 秘钥。
我们经常要向容器传递敏感信息,最常见的莫过于密码了。比如: docker run -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql 在启动 MySQL 容器时我们通过环境变量 MYSQL_ROOT_PASSWORD 设置了 MySQL 的管理员密码。
容器状态是 UP 的,应用就是健康的吗? 还真不一定!Docker 只能从容器启动进程的返回代码判断其状态,而对于容器内部应用的运行情况基本没有了解。 执行 docker run 命令时,通常会根据 Dockerfile 中的 CMD 或 ENTRYPOINT 启动一个进程,这个进程的状态就是 docker ps STATUS 列显示容器的状态。
上一节我们讨论了 Service 部署的两种模式:global mode 和 replicated mode。无论采用 global mode 还是 replicated mode,副本运行在哪些节点都是由 Swarm 决定的,作为用户我们有没有可能精细控制 Service 的运行位置呢? 答案是:能,使用 label。
Swarm 可以在 service 创建或运行过程中灵活地通过 --replicas 调整容器副本的数量,内部调度器则会根据当前集群的资源使用状况在不同 node 上启停容器,这就是 service 默认的 replicated mode。
上一节我们成功将 Rex-Ray Volume 挂载到了 Service。本节验证 Failover 时,数据不会丢失。 Scale Up 增加一个副本: docker service update --replicas 2 my_web 运行之前我们先推测一下,理想的结果应该是:swarm 在 swarm-worker2 上启动第二个副本,同时也将挂载 volume my_web。
service 的容器副本会 scale up/down,会 failover,会在不同的主机上创建和销毁,这就引出一个问题,如果 service 有要管理的数据,那么这些数据应该如何存放呢? 选项一:打包在容器里。
在前面的实验中,我们部署了多个副本的服务,本节将讨论如何滚动更新每一个副本。 滚动更新降低了应用更新的风险,如果某个副本更新失败,整个更新将暂停,其他副本则可以继续提供服务。同时,在更新的过程中,总是有副本在运行的,因此也保证了业务的连续性。
微服务架构的应用由若干 service 组成。比如有运行 httpd 的 web 前端,有提供缓存的 memcached,有存放数据的 mysql,每一层都是 swarm 的一个 service,每个 service 运行了若干容器。
接上一节案例,当我们访问任何节点的 8080 端口时,swarm 内部的 load balancer 会将请求转发给 web_server 其中的一个副本。 这就是 routing mesh 的作用。 所以,无论访问哪个节点,即使该节点上没有运行 service 的副本,最终都能访问到 service。
前面我们已经学习了如何部署 service,也验证了 swarm 的 failover 特性。不过截止到现在,有一个重要问题还没有涉及:如何访问 service?这就是本节要讨论的问题。 为了便于分析,我们重新部署 web_server。
故障是在所难免的,容器可能崩溃,Docker Host 可能宕机,不过幸运的是,Swarm 已经内置了 failover 策略。 创建 service 的时候,我们没有告诉 swarm 发生故障时该如何处理,只是说明了我们期望的状态(比如运行3个副本),swarm 会尽最大的努力达成这个期望状态,无论发生什么状况。
上一节部署了只有一个副本的 Service,不过对于 web 服务,我们通常会运行多个实例。这样可以负载均衡,同时也能提供高可用。 swarm 要实现这个目标非常简单,增加 service 的副本数就可以了。
上一节我们创建好了 Swarm 集群, 现在部署一个运行 httpd 镜像的 service,执行如下命令: docker service create --name web_server httpd 部署 service 的命令形式与运行容器的 docker run 很相似,--name 为 service 命名,httpd 为镜像的名字。
本节我们将创建三节点的 swarm 集群。 swarm-manager 是 manager node,swarm-worker1 和 swarm-worker2 是 worker node。
从主机的层面来看,Docker Swarm 管理的是 Docker Host 集群。所以先来讨论一个重要的概念 - 集群化(Clustering)。 服务器集群由一组网络上相互连接的服务器组成,它们一起协同工作。
上一节已经部署好了 Graylog,现在学习如何用它来管理日志。 首先启动测试容器。 docker run -d \ --log-driver=gelf \ --log-opt gelf-address=udp://localhost:12201 \ ...
Graylog 是与 ELK 可以相提并论的一款集中式日志管理方案,支持数据收集、检索、可视化 Dashboard。本节将实践用 Graylog 来管理 Docker 日志。 Graylog 架构 Graylog 架构如下图所示: Graylog 负责接收来自各种设备和应用的日志,并为用户提供 Web 访问接口。
前面的 ELK 中我们是用 Filebeat 收集 Docker 容器的日志,利用的是 Docker 默认的 logging driver json-file,本节我们将使用 fluentd 来收集容器的日志。
上一节已经部署了容器化的 ELK,本节讨论如何将日志导入 ELK 并进行图形化展示。 几乎所有的软件和应用都有自己的日志文件,容器也不例外。前面我们已经知道 Docker 会将容器日志记录到 /var/lib/docker/containers//-json.log,那么只要我们能够将此文件发送给 ELK 就可以实现日志管理。
在开源的日志管理方案中,最出名的莫过于 ELK 了。ELK 是三个软件的合称:Elasticsearch、Logstash、Kibana。 Elasticsearch一个近乎实时查询的全文搜索引擎。Elasticsearch 的设计目标就是要能够处理和搜索巨量的日志数据。
将容器日志发送到 STDOUT 和 STDERR 是 Docker 的默认日志行为。实际上,Docker 提供了多种日志机制帮助用户从运行的容器中提取日志信息。这些机制被称作 logging driver。
高效的监控和日志管理对保持生产系统持续稳定地运行以及排查问题至关重要。 在微服务架构中,由于容器的数量众多以及快速变化的特性使得记录日志和监控变得越来越重要。考虑到容器短暂和不固定的生命周期,当我们需要 debug 问题时有些容器可能已经不存在了。
前面我们已经介绍了ps/top/stats、Sysdig、Weave Scope、cAdvisor 和 Prometheus 多种容器监控工具和方案,是时候做一个比较了。下面将从五个方面来对比它们之间的优劣。
上一节介绍了 Prometheus 的核心,多维数据模型。本节演示如何快速搭建 Prometheus 监控系统。 环境说明 我们将通过 Prometheus 监控两台 Docker Host:192.168.56.102 和 192.168.56.103,监控 host 和容器两个层次的数据。
本节讨论 Prometheus 的核心,多维数据模型。我们先来看一个例子。 比如要监控容器 webapp1 的内存使用情况,最传统和典型的方法是定义一个指标 container_memory_usage_bytes_webapp1 来记录 webapp1 的内存使用数据。
Prometheus 是一个非常优秀的监控工具。准确的说,应该是监控方案。Prometheus 提供了监控数据搜集、存储、处理、可视化和告警一套完整的解决方案。 让我们先来看看 Prometheus 的架构。
cAdvisor 是 google 开发的容器监控工具,我们来看看 cAdvisor 有什么能耐。 在 host 中运行 cAdvisor 容器。 docker run \ --volume=/:/rootfs:ro \ --volume=/var/run...
除了监控容器,Weave Scope 还可以监控 Docker Host。 点击顶部 HOSTS 菜单项,地图将显示当前 host。 与容器类似,点击该 host 图标将显示详细信息。 host 当前的资源使用情况和历史曲线一览无余。