本系列文章记录了企业客户在应用Kubernetes时的一些常见问题
<a href="https://yq.aliyun.com/articles/562440">第一篇：Java应用资源限制的迷思</a>
<a href="https://yq.aliyun.com/articles/566208">第二篇：利用LXCFS提升容器资源可见性</a>
<a href="https://yq.aliyun.com/articles/573791">第三篇：解决服务依赖</a>
在容器服务的客户群中，一个经常被问起的问题就是如何处理服务间依赖。
在应用中，一个组件依赖指定的中间件服务和业务服务。在传统的软件部署方式中，应用启动、停止都要依照特定的顺序完成。
当采用 Kubernetes/Docker Swarm等容器编排技术在分布式环境下部署应用时，一方面不同组件之间并行启动无法保证其启动顺序，另一方面在应用运行时，其所依赖的服务实现有可能发生失败和迁移。如何解决容器之间的服务依赖就是一个非常常见的问题。
我们可以在应用的启动逻辑中添加服务依赖检查逻辑，如果应用依赖的服务不可访问就重试，当错误超过一定次数后就自动退出。Kubernetes/Docker会根据所容器的重启策略(Restart Policy)在等待一段时间之后自动拉起。
下面就是一个简单的Golang应用示例，来检测所依赖的MySQL服务是否就绪。
注：
"Fail Fast" (快速失败)，是Design by Contract契约式设计的一种重要的原则，可以很好地保障系统的健壮性和可预测性。比如上文代码中，如果重试失败，就会由<code>log.Fatal(dbError)</code> 退出执行。而K8S/Docker的容器重启的回退机制可以保障不会因频繁拉起失败应用导致系统资源耗尽。
在现实世界里，有些遗留应用或者框架无法进行调整。我们就会希望将依赖检查策略和应用逻辑进行解耦。
首先在Pod中有三类容器
infra container: 这就是著名的pause容器
main container: 应用容器
Kubernetes的最佳实践中，通常是利用初始化容器来进行依赖服务的检查。下面我们通过一个Wordpress的实例来展示其使用方法。
我们在Wordpress Deployment的Pod定义中添加了<code>initContainers</code>，它会通过检查 <code>mysql</code> 域名是否可以解析来判断所依赖的mysql服务是否就绪。
同时，在MySQL StatefulSet中我们也引入了<code>readinessProbe</code> 和 <code>livenessProbe</code>探针，它们会判定是否MySQL进程已经业务就绪。在K8S中，只有健康的Pod才可以通过ClusterIP访问或者DNS解析。
Liveness探针：主要用于判断Container是否处于运行状态，比如当服务死锁或者响应缓慢等情况。
Readiness探针：主要用于判断服务是否已经正常工作。
在init container中不允许使用readiness探针。
如果Pod重启了，其所有init Container都需重新运行。
本文介绍了常见的解决方法来实现服务的依赖检查，还进一步用示例展示了如何利用init container， liveness/readiness探针等技术实现服务健康检查，依赖检查等等功能。
Kubernetes提供了非常灵活的Pod生命周期管理机制，由于篇幅有限我们就不再展开介绍 postStart/preStop等生命周期钩子方法。