服务发现指的是确定如何连接服务的过程。要获得容器以及云原生应用的很多收益，我们需要将配置从容器镜像中移除出去，这样的话，我们就能把相同的容器镜像应用到所有的环境中。将配置提取到应用外部是12要素应用的核心原则之一。服务发现是从运行时环境中获取配置信息的方式之一，这样能够避免将其硬编码到应用之中。Kubernetes自带了。Kubernetes还提供了ConfigMaps和[Secrets] (https://kubernetes.io/docs/concepts/configuration/secret/)用来将配置从应用容器中移除。在运行时环境中，如果要连接数据库这样的服务，我们会存储凭证信息，Secrets解决了一些这方面所面临的挑战。
借助Kubernetes，我们无需使用外部的服务器或框架。尽管我们可以通过Kubernetes YAML文件管理每个运行时环境的配置，但是Red Hat OpenShift提供了GUI和CLI，能够让DevOps团队更容易地管理配置信息。
2.基本调用容器中的应用可以通过Ingress进行访问，也就是从外部世界路由到你所暴露的服务。OpenShift提供了基于HAProxy的，它具有各项功能和负载均衡策略。你可以使用路由功能进行轮流部署。这可以作为一些非常复杂的CI/CD策略的基础。参见下文的“6.构建和部署管道”。
如果你想运行一次性的任务，比如一个批处理或者只是使用集群来计算一个结果（比如计算Pi的位数），那该怎么办呢？针对这种场景，Kubernetes提供了job objects。同时还有一个cron job，能够管理基于时间的任务。
3.弹性在Kubernetes中，弹性（elasticity）是通过ReplicaSets（它过去被称为Replication Controllers）解决的。与面向Kubernetes的大多数配置类似，ReplicaSet是一种协调所需状态的方式：你告诉Kubernetes，系统应该处于各种状态，Kubernetes就能知道如何达到该状态。在任意时间，ReplicaSet都能控制副本的数量或应用程序精确的实例数量。
但是，如果你所构建的服务受欢迎程度超出了预先的规划，计算资源耗尽了该怎么办呢？你可以借助Kubernetes ，它会基于观测到的CPU利用率（或所支持的自定义指标，以及应用提供的指标）扩展pod的数量。
4.日志因为Kubernetes集群能够运行容器化应用的多个副本，所以将这些日志聚合起来，以便于在同一个地方进行查看就变得非常重要了。同时，为了利用自动扩展（以及其他云原生应用的功能）所带来的收益，容器应该是不可变的。所以，我们应该将日志存储在容器之外，这样它们才能跨运行时持久化。OpenShift允许我们部署EFK技术栈来聚合来自主机和应用的日志，即便这些日志来自多个容器甚至已删除的pod均是可以的。
EFK技术栈的组成如下所示：
5.监控尽管日志和监控看上去解决的是相同的问题，但是它们之间是不同的。监控是观察、检查、通常还有告警以及记录，而日志则只有记录。
Prometheus是一个开源的监控系统，它包含了时序数据库。它可以用来存储和查询指标、告警，并使用可视化的方式查看系统内部的运行状况。Prometheus可能是监控Kubernetes集群方面最流行的可选方案。在Red Hat开发人员博客上，有多篇介绍使用Prometheus进行监控的文章。在OpenShift博客上，也能找到关于Prometheus的文章。
你还可以看到Prometheus和Istio实际结合使用的教程。
6.构建和部署管道对于你的应用来说，CI/CD（持续集成/持续交付）并不是“必备”的要求。但是，CI/CD通常被认为是成功软件开发和DevOps实践的支柱。如果没有经过CI/CD管道的话，软件不应该发布到生产环境中。Jez Humble和David Farley合著的《持续交付：发布可靠软件的系统方法》中是这样描述CD的：“持续交付能够将各种类型的变更发布到生产环境中，包括新特性、配置变化、缺陷修正以及体验性的功能，或者说以可持续的方式将这些变更安全且快速地交到用户的手里”。