微服务-kubernetes
当我们的web应用跑在容器中，如何扩容？如何管理容器间的调用，负载均衡？自己手动新建nginx管理？自己手动改代码完成？不用。已经有大牛为我们造好了轮子---Kubernetes，它是一个容器控制平台。
Kubernetes 通过一个简单的 API 提供底层基础设施的抽象，我们可以向该 API 发送请求。这些请求可以让 Kubernetes 尽最大能力应对。例如，可以简单地要求“Kubernetes 添加映像 x 的 4 个容器。”然后 Kubernetes 会找出使用中的节点，并在内添加新的容器。
image
这对开发人员来说意味着什么？意味着开发人员不需要在意节点的数目，也不需要在意从哪里运行容器以及如何与它们交流。开发人员不需要管理硬件优化，或担心节点关闭（它们将遵循墨菲法则），因为新的节点会添加到 Kubernetes 集群。同时 Kubernetes 会在其他运行的节点中添加容器。Kubernetes 会发挥最大的作用。
在图中我们看到了一些新东西：
API服务器：与集群交互的唯一方式。负责启动或停止另外一个容器，或检查当前状态，日志等；
Kubelet：监视节点内的容器，并与主节点交流；
Pod：初始阶段我们可以把 pod 当成容器。
Pod
Kubernetes 给我们最小的可部署计算单元 Pod 。它可以理解为一个逻辑宿主机，可以启动一个或者多个容器，这些容器共享同一个端口空间，他们可以通过 localhost 交流，与其他 Pod 内容器的交流可以通过结合 Pod 的 IP 完成。
一个 Pod 内的容器共享同一个卷、同一个 IP、端口空间、IPC 命名空间。
注：容器有个自己独立的文件系统，尽管他们可以通过 Kubernetes 的资源卷共享数据
pod.yaml文件编写方式：
apiVersion: v1
kind: Pod
metadata:
name: sa-frontend
labels:
app: sa-frontend
spec:
containers:
- image: rinormaloku/sentiment-analysis-frontend
name: sa-frontend
ports:
- containerPort: 80
- kind：指定我们想创建的 Kubernetes 资源的类型。这里是 Pod。
- name：定义该资源的名字。我们在这里命名为 sa-frontend。
- spec：该对象定义了资源应有的状态。Pod Spec 中最重要的属性是容器的数组。
- image：是指我们希望在本 Pod 中启动的容器的映像。
- name：Pod 中容器中唯一的名字。
- containerPort：是指容器监听的端口号。
终端输入
kubectl apply -f pod.yaml
创建pod
Service
Kubernetes 服务资源可以作为一组提供相同服务的 Pod 的入口。这个资源肩负发现服务和平衡 Pod 之间负荷的重任。
在 Kubernetes 集群内，我们拥有提供不同服务的 Pod（前端、Spring 网络应用和 Flask Python 应用程序）。所以这里的问题是：服务如何知道该处理哪个 Pod？例如：它如何生成这些 Pod 的终端列表？
这个问题可以用标签来解决，具体分两个步骤：
- 给所有服务处理的对象 Pod 贴上标签(label)；
- 在服务中使用一个选择器(selector)，该选择器定义了所有贴有标签的对象 Pod。
image.png
service.yaml文件编写方式:
apiVersion: v1
kind: Service
metadata:
name: sa-frontend-lb
spec:
type: LoadBalancer
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: sa-frontend
- kind：服务；
- type：指定类型，我们选择 LoadBalancer，因为我们想平衡 Pod 之间的负荷；
- ports：指定服务获取请求的端口；
- protocol：定义交流；#5 targetPort：可以将来访的请求转发到这个端口；
- selector：包含选择pod属性的对象；
- app：sa-frontend定义了哪个是目标 Pod，只有拥有标签“app: sa-frontend”的才是目标 Pod。
终端输入
kubectl apply -f service.yaml
创建service
Deployment
Kubernetes 部署可以帮助每一个应用程序的生命都保持相同的一点：那就是变化。此外，只有挂掉的应用程序才会一尘不变，否则，新的需求会源源不断地涌现，更多代码会被开发出来、打包以及部署。这个过程中的每一步都有可能出错。
部署资源可以自动化应用程序从一版本升迁到另一版本的过程，并保证服务不间断，如果有意外发生，它可以让我们迅速回滚到前一个版本。
现在我们有两个 Pod 和一个服务开放，而且它们之间有负载均衡。我们提到过现有的 Pod 还远远不够完美。需要分开管理每一个 Pod（创建、更新、删除和监视他们的情况）。快速更新和迅速回滚根本不可能！这样是不行的，部署 Kubernetes 资源可以解决这里的每个问题。
image.png
deployment.yaml文件编写方式：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: sa-frontend
spec:
replicas: 2
minReadySeconds: 15
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
template:
metadata:
labels:
app: sa-frontend
spec:
containers:
- image: rinormaloku/sentiment-analysis-frontend
imagePullPolicy: Always
name: sa-frontend
ports:
- containerPort: 80
- kind：部署；
- replicas：是部署 Spec 对象的一个属性，定义了我们想运行多少的 Pod。所以是 2；
- type：指定从当前版本升迁到下个版本的时候，部署使用的策略。此处的策略 RollingUpdate 可以保证部署期间服务不间断；
- maxUnavailable：是 RollingUpdate 对象的一个属性，定义了在升级的时候，最大允许停止的 Pod 数量（与希望的状态相比）。对我们的部署来说，我们有 2 个副本，这意味着在一个 Pod 停止后，我们还会有另外一个 Pod 运行，所以可以保证应用程序可访问；
- maxSurge：是 RollingUpdate 对象的另一个属性，定义了添加到部署的最大 Pod 数量（与希望的状态相比）。对我们的部署来说，这意味着在向新版本迁移的时候，我们可以加一个 Pod，那么我们可以同时拥有个 3 个 Pod；
- template：指定 Pod 的模板，部署在创建新 Pod 的时候，会用到该模板。很可能这个非常相似的 Pod 会立即吸引你；
- app: sa-frontend：根据模板创建的 Pod 将被贴上该标签；
- imagePullPolicy：当设置成 Always 的时候，每一次新部署都会重新获取容器映像。
终端输入
kubectl apply -f deployment.yaml
创建deployment
