系列文章：

容器 & 服务：开篇，压力与资源

容器 & 服务：Jenkins 本地及 docker 安装部署

容器 & 服务：Jenkins 构建实例

容器 & 服务：一个 Java 应用的 Docker 构建实战

容器 & 服务：Docker 应用的 Jenkins 构建

容器 & 服务：Docker 应用的 Jenkins 构建 (二)

容器 & 服务：K8s 与 Docker 应用集群 (一)

容器 & 服务：K8s 与 Docker 应用集群 (二)



关注公众号：程序员架构进阶，获取更多资料。

一 回顾

前面我们使用 docker 和 k8s 完成了 demo 程序的构建，这里做一下初步总结。

二 常用故障排除方法

上一篇在部署的过程中个，遇到了不少问题，例如镜像拉取失败，启动出错等等，遇到问题时，需要通过一些手段去了解错误原因，好定位问题，并最终解决问题。

最常见的操作可以使用以下 kubectl 命令完成：

• kubectl get - 列出资源

• kubectl describe - 显示有关资源的详细信息

• kubectl logs - 打印 pod 和其中容器的日志

• kubectl exec - 在 pod 中的容器上执行命令

我们可以使用这些命令查看应用程序的部署时间，当前状态，运行位置以及配置。

三 应用暴露

应用创建之后，需要暴露服务，这样才能被其他服务/节点访问，k8s 是通过 Service 来暴露的。从前面的操作也可以了解到，Pod 有生命周期，当一个工作节点（Node）挂掉之后，在这个 Node 上的 Pod 也会消亡。这时候就需要一个副本机制：ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。

假设一个后端程序/服务/应用有多个副本，这些副本是可替换的; 前端的系统不需要关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。

K8s 的 Service 是一个抽象概念，定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML (更推荐，所以很多时候我们都是面向 yaml 编程) 或者 JSON 来定义. Service 下的一组 Pod 通常由 LabelSelector 来标记。

Service 也可以用在 ServiceSpec 标记type的方式暴露，包括四种：

• ClusterIP (默认) - 在集群的内部 IP 上公开 Service 。这种类型使得 Service 只能从集群内访问。

• NodePort - 使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用<NodeIP>:<NodePort> 从集群外部访问 Service。是 ClusterIP 的超集。

• LoadBalancer - 在当前云中创建一个外部负载均衡器(如果支持的话)，并为 Service 分配一个固定的外部 IP。是 NodePort 的超集。

• ExternalName - 通过返回带有该名称的 CNAME 记录，使用任意名称(由 spec 中的externalName指定)公开 Service。不使用代理。这种类型需要kube-dns的 v1.7 或更高版本。

Service 与 Pod 的关系如下图所示：

与 Label、Deployment 的关系：