微服务-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