概述

Kubernetes　Pod 是平凡的，它门会被创建，也会死掉（生老病死），并且他们是不可复活的。 ReplicationControllers 动态的创建和销毁 Pods(比如规模扩大或者缩小，或者执行动态更新)。每个 pod 都由自己的 ip，这些 IP 也随着时间的变化也不能持续依赖。这样就引发了一个问题：如果一些 Pods（让我们叫它作后台，后端）提供了一些功能供其它的 Pod 使用（让我们叫作前台），在 kubernete 集群中是如何实现让这些前台能够持续的追踪到这些后台的？

答案是：Service

Kubernete Service 是一个定义了一组 Pod 的策略的抽象，我们也有时候叫做宏观服务。这些被服务标记的 Pod 都是（一般）通过 label Selector 决定的（下面我们会讲到我们为什么需要一个没有 label selector 的服务）

举个例子，我们假设后台是一个图形处理的后台，并且由 3 个副本。这些副本是可以相互替代的，并且前台并需要关心使用的哪一个后台 Pod，当这个承载前台请求的 pod 发生变化时，前台并不需要直到这些变化，或者追踪后台的这些副本，服务是这些去耦

对于 Kubernete 原生的应用，Kubernete 提供了一个简单的 Endpoints API，这个 Endpoints api 的作用就是当一个服务中的 pod 发生变化时，Endpoints API 随之变化，对于哪些不是原生的程序，Kubernetes 提供了一个基于虚拟 IP 的网桥的服务，这个服务会将请求转发到对应的后台 pod

Kubernetes 是一个开源的自动化部署，

Secrets 构建

yaml 构建

1
2
3
4
5
6
7
8
9

test-secret.yaml：
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: MWYyZDFlMmU2N2Rm
  username: YWRtaW4=

这篇文章主要介绍怎样部署一个 高可用(HA) 的 Kubernetes 集群。这是一个相当高阶的主题。

概述

建立一个真正可靠、高可用性的分布式系统需要若干步骤，它就像是穿着内衣、裤子、皮带、吊带，另外一对内裤和另一条裤子。下面，我们对这些步骤进行详细的探究，但在这里进行了一些总结，以帮助指导用户。

所涉及的步骤如下：

-
-
-
-

k8s 支持一下类型的 volumes

1. emptyDir
2. hostPath
3. gcePersistentDisk
4. awsElasticBlockStore
5. nfs
6. iscsi
7. flocker
8. glusterfs
9. rbd
10. cephfs
11. gitRepo
12. secret
13. persistentVolumeClaim
14. downwardAPI
15. azureFileVolume
16. azureDisk
17. vsphereVolume
18. Quobyte