Kubernetes 处理网络的方式和Docker不同，主要需要解决四种问题：

1. 高度耦合的Container之间的网络通信：这个由Pod和localhost通信解决了；
2. Pod和Pod之间的网络通信，这个是本篇的主要内容；
3. Pod和Service之间的通信，这个是由Service解决的；
4. 外部Service和内部Service之间的通信，这个也是由Service解决的。

在我之前的kubernetes中的Service中，我们可以看到如何使用Service来让我们的应用可以被集群外所访问到。但是在实际使用中，仍然存在一些问题。对于我们经常用的NodePort和LoadBalancer这两个type，LoadBalancer需要底层的infra支持，并且哪怕支持了我们也不能轻易用，因为LoadBalancer资源是有限的，而且最重要的是贵，贵，贵。而对于NodePort来说，我们需要经常更新我们的proxy设置，并且追踪哪些Port被使用了，所以也是很麻烦的。

万能的程序猿总是有解决方案，ingress应运而生。

为什么要有这俩玩意儿？

我们在kubernetes上部署应用的时候，经常会需要传一些配置给我们的应用，比如数据库地址啊，用户名密码啊之类的。我们要做到这个，有好多种方案，比如：

• 我们可以直接在打包镜像的时候写在应用配置文件里面，但是这种方式的坏处显而易见而且非常明显。
• 我们可以在配置文件里面通过env环境变量传入，但是这样的话我们要修改env就必须去修改yaml文件，而且需要重启所有的container才行。
• 我们可以在应用启动的时候去数据库或者某个特定的地方拿，没问题！但是第一，实现起来麻烦；第二，如果配置的地方变了怎么办？

当然还有别的方案，但是各种方案都有各自的问题。

而且，还有一个问题就是，如果说我的一个配置，是要多个应用一起使用的，以上除了第三种方案，都没办法进行配置的共享，就是说我如果要改配置的话，那得一个一个手动改。假如我们有100个应用，就得改100份配置，以此类推……

kubernetes对这个问题提供了一个很好的解决方案，就是用ConfigMap和Secret。

我们都知道，容器是一个短暂的不稳定的存在（随时可能挂掉），挂掉之后里面的所有数据都没了，但是我们会有很多数据是需要一直存下来（持久化）的，那怎么办呢？思路很简单，把容器里面的数据存到一个可以持久化的地方（比如s3上）。

Service 是kubernetes中一个很重要的，也是很有用的概念，我们可以通过service来将pod进行分组，并提供外网的访问endpoint。在这个过程中还有比如kube-proxy提供了对service的访问。

Kubernetes中有很多积木（Building Blocks），比如object model，pod，rs，deployment，namespace之类，这些都是kubernetes中很重要的东西。

在这篇文章里，会主要记录一下kubernetes安装相关的信息。

最近正在复习准备考试，于是一边复习一遍写成博客，印证自己所学。

为什么引子我还要写一篇文章呢？因为引子介绍了很多关于大脑认知的知识，这本书运用了其中的很多知识来写作，这也是这本书为什么如此火如此出名的原因。我认为这可能会对我工作或者学习产生帮助，所以记录下来。

简介

kubeadm是一个kubernetes官方提供的快速安装和初始化拥有最佳实践（best practice）的kubernetes集群的工具，虽然目前还处于 beta 和 alpha 状态，还不能用在生产环境，但是我们可以通过学习这种部署方法来体会一些官方推荐的kubernetes最佳实践的设计和思想。