上次 ，我们研究了使用微服务的两种方法。 特别是其中之一涉及使用Docker容器，您可以在其中执行微服务和辅助程序的代码。 今天，使用我们现有的容器映像，我们将与Kubernetes合作。
Kubernetes简介
我保证，当您阅读本文时，我一点也不夸张，问自己：“为什么Kubernetes不被称为Supernetes？”
超级网如果您阅读了本材料的前一部分，那么您会知道，我们在这里了解了许多与准备容器化应用程序和使用Docker容器相关的内容。 在您看来，最困难的事情现在正在等待着您，但是，实际上，我们在这里要谈论的要比我们已经发现的要简单得多。 对于某人来说，学习Kubernetes似乎是一项艰巨的任务的唯一原因是因为您需要了解Kubernetes并有效使用它的大量附加信息。 我们已经讨论了成功开发Kubernetes所需的所有“附加信息”。
Ku什么是Kubernetes？
在本文的第一部分中，在容器中启动微服务后，要求您考虑扩展容器化应用程序的问题。
我建议以问答形式共同思考：
问题：容器化应用程序如何扩展？
答：启动其他容器。
问题：负载之间如何分配？ 如果某个服务器已被最大程度地使用，并且该容器需要部署在另一台服务器上，该怎么办？ 如何找到最有效的硬件使用方式？
答：所以...我将在互联网上寻找...
问题：如何在不中断系统的情况下更新程序？ 并且，如果更新中包含错误，如何返回到应用程序的工作版本？
实际上，正是Kubernetes技术为这些问题和许多其他问题提供了有价值的答案。 我会尝试将Kubernetes的定义缩小为一句话：“ Kubernetes是一个容器管理系统，它抽象化了基础架构（容器运行的环境）。”
我相信，尽管我们已经提到了“容器管理”的概念，但现在您还不是很清楚。 下面我们将在实践中考虑该技术。 但是，首先遇到了“抽象基础设施”的概念。 因此，现在我们考虑一下。
basic基础设施的抽象
Kubernetes允许应用程序从基础架构中抽象出来，从而为我们提供了一个简单的API，您可以向其发送请求。 Kubernetes尝试使用其所有功能来满足这些要求。 例如，以常规语言，类似的请求可以描述如下：“ Kubernetes，扩展4个图像容器X”。 收到命令后，Kubernetes会发现不太繁忙的节点（它们也称为“节点”，英文为“ node”），可以在其上部署新容器。
API服务器请求这对开发人员意味着什么？ 这意味着他无需担心节点的数量，容器的确切启动位置或它们之间的交互方式。 他不必处理硬件优化，也不必担心节点可能发生故障（根据墨菲定律，类似的事情肯定会发生），因为如有必要，可以将新节点添加到Kubernetes集群中。 如果某些现有节点出了问题，Kubernetes会将容器部署到仍处于健康状态的那些节点。
上图中显示的大部分内容已经为您所熟悉。 但是，还有一些新的东西：
- API服务器 调用此服务器是与我们拥有的群集进行交互的唯一方法，无论是讨论启动或停止容器，检查系统状态，使用日志还是执行其他操作。
- Kubelet。 这是一个代理，它监视节点内部的容器并与主节点进行交互。
请注意，在前面的几句话中，我们使用术语“容器”，但是在这里使用术语“ pod”会更正确。 这些实体在俄语出版物中通常被称为“豆荚”，有时在
文档中也被称为“豆荚”，以澄清“豆荚”的概念，它们被称为“鲸鱼群”（“鲸豆荚”）或“豌豆荚”但是没有人称它们为“群”或“豆荚”。 说到它们，我们将使用“下”一词。 现在您可以考虑使用它们作为容器了，下面我们将详细讨论Pod。
我们现在将停止在此，因为我们可以进一步讨论所有这些，此外，还有很多有关Kubernetes理论的好材料。 例如，这虽然不容易阅读，但却是官方文档，或者像
这样的书。
with与云服务提供商的工作标准化
Kubernetes的另一个优势在于，该技术有助于与云服务提供商（Cloud Service Provider，CSP）的工作标准化。 这是一个大胆的声明。 考虑以下示例。 熟悉Azure或Google Cloud Platform的专家必须为他设计一个为全新的云环境设计的项目，而他对此并不熟悉。 在这种情况下，很多事情都会出错。 例如，项目交付的最后期限可能会延迟，项目的客户公司可能需要租用比计划更多的云资源，依此类推。
在使用Kubernetes时，根本不会出现这样的问题，因为无论我们在谈论哪个特定的云服务提供商，使用Kubernetes的工作总是一样。 开发人员以声明式的方式告诉API服务器他需要什么，而Kubernetes使用系统的资源，从而允许开发人员忽略该系统实现的细节。
对这个想法留一点点，因为这是一个非常强大的Kubernetes机会。 对于公司而言，这意味着他们的决策不依赖于特定的CSP。 如果公司在云服务市场上找到更好的报价，则可以通过迁移到新的提供商来自由地利用此报价。 此外，公司专家获得的经验不会在任何地方丢失。
现在让我们谈谈Kubernetes的实际使用
Kubernetes实践：豆荚
我们在容器中配置了微服务的启动，设置过程非常繁琐，但是我们设法进入了一个工作系统。 此外，如前所述，我们的解决方案扩展性不好，并且无法抵抗故障。 我们将使用Kubernetes解决这些问题。 接下来，我们将把系统带到与以下方案相对应的形式。 即，这些容器将由Kubernetes管理。
微服务在Kubernetes管理的集群中工作在这里，我们将使用Minikube进行集群的本地部署并测试Kubernetes的功能，尽管我们在此要做的所有工作都可以使用Azure或Google Cloud Platform等云平台来完成。
Mini安装和启动Minikube
要安装Minikube，请遵循
文档中的
说明 。 在安装Minikube的过程中，您还将安装Kubectl。 这是一个允许向Kubernetes API服务器发出请求的客户端。
要启动Minikube，请运行
minikube start命令，完成后，请运行
kubectl get nodes命令。 如此一来，您应该看到类似以下内容：
kubectl get nodes NAME STATUS ROLES AGE VERSION minikube Ready <none> 11m v1.9.0
Minikube让我们使用一个仅包含一个节点的集群。 是的，这很适合我们。 使用Kubernetes的人不必担心集群中到底有多少个节点，因为Kubernetes允许您从此类细节中抽象出来。
现在让我们谈谈豆荚。
▍豆荚
我真的很喜欢容器，现在您可能也喜欢它们。 为什么Kubernetes可以让我们使用Pod，这些实体是该系统中可部署的最小计算单元？ 它执行什么功能？ 事实是，炉床可能包括一个或多个共享相同运行时的容器。
但是，是否有必要在一个炉床上进行两个容器的搬运？ How to say ...通常每个容器只有一个容器，这就是我们要做的。 但是对于某些情况，例如，当两个容器需要共享访问同一数据仓库，或者使用进程间通信技术进行连接，或者由于其他原因而紧密连接时，所有这些都可以实现通过将它们放在一个炉膛中 Pod不同的另一种可能性是，它们不必使用Docker容器。 如有必要，您可以在此处将其他技术应用于应用程序的容器化，例如
-Rkt 。
下图显示了编号的炉床属性。
炉床特性考虑这些属性。
- Kubernetes集群中的每个Pod都有一个唯一的IP地址。
- 炉膛可以容纳许多容器。 它们共享可用的端口号，例如，它们可以通过
localhost相互交换信息（自然，它们不能使用相同的端口）。 使用位于其他容器中的容器的IP地址来组织与容器的交互。 - Pod中的容器共享数据存储卷，IP地址，端口号，IPC名称空间。
应该注意的是，容器具有自己的隔离文件系统，但是它们可以使用称为
Volume的Kubernetes资源共享数据。
对我们来说，关于炉膛的说法足以继续掌握Kubernetes。
在此处阅读有关它们的更多信息。
▍壁炉的描述
以下是
sa-frontend应用程序的清单文件。
apiVersion: v1 kind: Pod # 1 metadata: name: sa-frontend # 2 spec: # 3 containers: - image: rinormaloku/sentiment-analysis-frontend # 4 name: sa-frontend # 5 ports: - containerPort: 80
让我们解释其中指定的一些参数。
Kind ：指定我们要创建的Kubernetes资源的种类。 在我们的例子中，这是Pod 。Name ：资源名称。 我们称它为sa-frontend 。Spec ：描述资源所需状态的对象。 这里最重要的属性是容器数组。Image ：我们要在此容器中运行的容器的图片。Name ：下方容器的唯一名称。ContainerPort ：容器正在侦听的端口。 该参数可以视为是谁读取此文件的指示（如果省略此参数，则不会限制对端口的访问）。
▍创建炉膛SA-Frontend
我们讨论的pod描述文件可以在
resource-manifests/sa-frontend-pod.yaml 。 您必须使用终端工具转到该文件夹，或者在调用适当的命令时指定文件的完整路径。 这是此命令和系统对此命令的示例：
kubectl create -f sa-frontend-pod.yaml pod "sa-frontend" created
为了找出它是否在下面工作，请运行以下命令：
kubectl get pods NAME READY STATUS RESTARTS AGE sa-frontend 1/1 Running 0 7s
如果执行此命令期间炉床的状态为
ContainerCreating ，则可以使用
--watch运行相同的命令。 因此，当炉床处于
Running状态时，将自动显示有关此信息。
from从外部访问应用程序
为了从外部组织对应用程序的访问，创建服务类型的Kubernetes资源是正确的，我们将在下面讨论，但是为了简便起见，在这里，我们将使用简单的端口转发：
kubectl port-forward sa-frontend 88:80 Forwarding from 127.0.0.1:88 -> 80
如果现在通过
127.0.0.1:88浏览器，则可以看到React应用程序页面。
scaling错误的缩放方法
我们已经说过Kubernetes的功能之一就是应用程序扩展。 为了体验这一机会，我们将在下一个。 通过将以下代码放在
sa-frontend-pod2.yaml文件中，创建另一个
Pod资源的描述：
apiVersion: v1 kind: Pod metadata: name: sa-frontend2 # spec: containers: - image: rinormaloku/sentiment-analysis-frontend name: sa-frontend ports: - containerPort: 80
如您所见，如果将此说明与我们上面检查的内容进行比较，则唯一的变化就是
Name属性的值。
在下面创建一个新的：
kubectl create -f sa-frontend-pod2.yaml pod "sa-frontend2" created
确保它正在运行：
kubectl get pods NAME READY STATUS RESTARTS AGE sa-frontend 1/1 Running 0 7s sa-frontend2 1/1 Running 0 7s
现在我们有两个炉膛！ 没错，这里没有什么特别的享受。 请注意，此处显示的应用程序扩展问题的解决方案有很多缺点。 我们将在另一个名为Deployment的Kubernetes资源的部分中讨论如何做到这一点。
现在考虑启动两个相同的炉膛后得到的结果。 即，Nginx Web服务器现在在两个不同的Pod中运行。 在这方面，我们可以问两个问题：
- 如何通过URL允许从外部访问这些服务器？
- 如何组织它们之间的负载平衡？
错误的缩放方法在Kubernetes工具中，有服务形式的资源。 让我们谈谈他们。
Kubernetes实践：服务
Kubernetes服务充当炉床集的访问点，炉床集提供与这些炉床相同的功能。 服务执行解决使用炉床并平衡它们之间的负载的艰巨任务的解决方案。
Kubernetes服务提供IP地址在我们的Kubernetes集群中，将实现不同功能的Pod。 这是一个前端应用程序，一个Spring Web应用程序和一个用Python编写的Flask应用程序。 这就提出了一个问题，即服务应如何理解其需要使用哪些容器，即如何根据系统应为容器生成端点的列表的信息来查找服务。
这是通过另一个称为Label的Kubernetes抽象来完成的。 使用标签包括两个阶段：
- 标签分配将使服务可以使用。
- 将“选择器”应用于服务，确定选择了哪些标签的豆荚，该服务将起作用。
也许将其想象为比进行描述更容易。
带标签的吊舱及其清单文件我们在这里看到两个使用
app: sa-frontend构造的炉膛，它们分配了相同的标签。 该服务对带有此类标记的吊舱感兴趣。
▍标签
标签为开发人员提供了一种组织Kubernetes资源的简单方法。 它们是键值对；您可以将它们分配给任何资源。 修改前端应用程序炉床描述文件，并将它们带到上图所示的视图中。 之后，保存这些文件并运行以下命令：
kubectl apply -f sa-frontend-pod.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend" configured kubectl apply -f sa-frontend-pod2.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend2" configured
当执行这些命令时，系统将发出警告（我们不知道我们使用
apply而不是
create ，我们理解这一点），但是在警告之后，它会报告已配置相应的容器。 我们可以通过过滤要显示其信息的日志来检查是否为标签分配了标签：
kubectl get pod -l app=sa-frontend NAME READY STATUS RESTARTS AGE sa-frontend 1/1 Running 0 2h sa-frontend2 1/1 Running 0 2h
验证标签确实已分配标签的另一种方法是将
--show-labels键附加到上一个命令。 因此，有关其吊舱的信息还将包括其标记上的数据。
现在已经分配了标签，我们已经准备好配置服务以使用它们。 因此，我们将处理诸如
LoadBalancer之类的服务的描述。
使用诸如LoadBalancer之类的服务进行负载均衡▍服务说明
这是对诸如
LoadBalancer之类的服务的YAML描述：
apiVersion: v1 kind: Service # 1 metadata: name: sa-frontend-lb spec: type: LoadBalancer # 2 ports: - port: 80 # 3 protocol: TCP # 4 targetPort: 80 # 5 selector: # 6 app: sa-frontend # 7
解释这段文字：
Kind ：我们创建一个服务，一个Service资源。Type ：规范中指示的资源类型。 我们选择类型LoadBalancer ，因为使用此服务，我们要解决在炉床之间平衡负载的问题。Port ：服务在其上接受请求的端口。Protocol ：服务使用的协议。TargetPort ：将传入请求重定向到的端口。Selector ：一个对象，包含有关服务应与哪些容器一起使用的信息。app: sa-frontend ：此属性指示该服务将与哪些容器一起使用。 即，这些是已将app: sa-frontend标签分配到的Pod。
为了创建服务，您需要运行以下命令：
kubectl create -f service-sa-frontend-lb.yaml service "sa-frontend-lb" created
您可以按以下方式检查服务状态：
kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE sa-frontend-lb LoadBalancer 10.101.244.40 <pending> 80:30708/TCP 7m
在这里，您可以看到
EXTERNAL-IP属性处于
<pending>状态，但是您不能等待其更改。 这是由于我们使用了Minikube。 如果我们在与特定的云服务提供商（例如Azure或Google Cloud Platform）合作时创建了类似的服务，则该服务将具有一个公共IP地址，从而可以从Internet访问它。
尽管如此，Minikube仍然不允许我们乱搞，为我们提供了用于系统本地调试的有用命令：
minikube service sa-frontend-lb Opening kubernetes service default/sa-frontend-lb in default browser...
通过此命令，将启动浏览器以访问该服务。 服务接收到请求后，会将其重定向到一个炉膛（无论是哪个炉膛）。 这种抽象使我们可以将一组炉床视为一个单独的实体，并与它们一起工作，并将服务用作对它们的单个访问点。
在本节中，我们讨论了如何为资源分配标签，在将服务配置为选择器时如何使用标签。 在这里，我们描述并创建了一个类似于
LoadBalancer的服务。 由于这一点，我们解决了扩展应用程序的问题（扩展包括将带有相应标签的新炉床添加到群集），并使用服务作为入口点在炉床之间组织负载平衡。
Kubernetes实践：部署
部署是Kubernetes的抽象，它使我们能够控制应用程序生命周期中始终存在的内容。 这是关于管理应用程序更改的。 可以说，不变的应用程序是“死”应用程序。 如果应用程序“存在”，那么您可能会遇到这样的事实，即它的需求会定期更改，其代码会扩展，该代码会被打包和部署。 此外，在过程的每个步骤中都可能会出错。
部署类型的资源允许您自动化从应用程序的一个版本到另一个版本的过渡过程。 这是在不中断系统的情况下完成的，如果在此过程中发生错误，我们将有机会快速返回到应用程序的先前工作版本。
▍使用部署
现在，群集具有两个炉床和一个服务，该服务可从外部访问它们并平衡它们的负载。
集群当前状态我们谈到了一个事实，那就是运行两个具有相同功能的不同炉床不是一个好主意。 使用这种方案时，我们必须单独处理每个炉床，创建，更新，删除每个特定炉床，并观察其状态。 使用这种方法，无需谈论快速的系统更新或失败的更新的快速回滚。 我们对这种情况不满意，因此我们将诉诸于部署资源的可能性，该资源旨在解决上述问题。
在继续进行工作之前，让我们确定其目标，这将为我们提供一些准则，这些准则在解析部署清单文件时会派上用场。 所以这是我们需要的：
- 我们希望能够基于一个容器
rinormaloku/sentiment-analysis-frontend创建两个炉膛。 - 我们需要一个应用程序部署系统，使它在更新时可以不中断地工作。
- 我们希望为
app: sa-frontend标签分配app: sa-frontend ，这将允许sa-frontend-lb服务检测到这些吊舱。
现在，我们将这些要求表示为部署资源的描述。
▍部署说明
这是对部署类型资源的YAML描述，该描述是在考虑了上述系统要求之后创建的：
apiVersion: extensions/v1beta1 kind: Deployment # 1 metadata: name: sa-frontend spec: replicas: 2 # 2 minReadySeconds: 15 strategy: type: RollingUpdate # 3 rollingUpdate: maxUnavailable: 1 # 4 maxSurge: 1 # 5 template: # 6 metadata: labels: app: sa-frontend # 7 spec: containers: - image: rinormaloku/sentiment-analysis-frontend imagePullPolicy: Always # 8 name: sa-frontend ports: - containerPort: 80
让我们分析一下这个描述：
Kind ：此处表示我们正在描述“ Deployment视图的资源。Replicas ：部署规范对象的属性，用于定义要运行多少个炉床实例（副本）。Type ：描述从当前版本切换到新版本时此部署中使用的策略。 RollingUpdate策略可在升级期间将系统停机时间RollingUpdate零。MaxUnavailable ：这是RollingUpdate对象的属性，该对象设置执行顺序系统更新时不可用炉RollingUpdate的最大数量（与所需炉RollingUpdate数量相比）。 在我们的部署中，这意味着存在2个副本，此属性的值指示在完成一个pod的操作之后，将执行另一个pod，这将使应用程序在更新期间可用。MaxSurge ：这是RollingUpdate对象的属性，该属性描述可以添加到部署中的最大炉RollingUpdate数量（与给定的炉RollingUpdate数量相比）。 在我们的例子中，其值为1表示，当切换到该程序的新版本时，我们可以向集群添加另一个子项，这将导致最多可同时启动三个炉床的事实。Template ：此对象定义炉床模板，所描述的Deployment资源将用于创建新炉床。 您可能会发现此设置很熟悉。app: sa-frontend ：根据给定模式创建的炉膛标签。ImagePullPolicy ：定义图像的工作顺序。 在我们的示例中，此属性设置为Always ，即在每次部署期间，将从存储库中下载相应的映像。
研究完所有这些之后，让我们继续练习。 运行部署：
kubectl apply -f sa-frontend-deployment.yaml deployment "sa-frontend" created
检查系统状态：
kubectl get pods NAME READY STATUS RESTARTS AGE sa-frontend 1/1 Running 0 2d sa-frontend-5d5987746c-ml6m4 1/1 Running 0 1m sa-frontend-5d5987746c-mzsgg 1/1 Running 0 1m sa-frontend2 1/1 Running 0 2d
如您所见，现在我们有4个吊舱。 其中两个是使用Deployment资源创建的，另外两个是我们自己创建的。 现在，您可以使用以下类型的命令删除我们自己创建的那些吊舱：
kubectl delete pod <pod-name>
顺便说一下，这是一项独立工作。 删除使用“部署”资源创建的炉床之一，并监视系统。 在进一步阅读之前，请考虑一下发生情况的原因。
删除一个炉床时，部署资源会得知系统的当前状态（1个子）与所需状态（2个子）不同，因此将启动另一个子。
部署资源的用途是什么，除了使用时将系统保持在正确的状态之外？ 考虑这些资源的优势。
ing以零系统停机时间执行部署
假设有一位产品经理来找我们，并报告我们为其创建该产品的客户想要在客户应用程序中使用绿色按钮。 开发人员实现了这一要求，并为我们提供了我们唯一需要的东西-一个名为
rinormaloku/sentiment-analysis-frontend:green的图像容器。 现在是我们的时间。 DevOps团队我们需要部署更新的系统并确保零停机时间。 现在，让我们看看开发和配置Deployment资源的努力是否合理。
编辑
sa-frontend-deployment.yaml文件，用
rinormaloku/sentiment-analysis-frontend:green替换一个新的图像容器名称，然后将此文件另存为
sa-frontend-deployment-green.yaml并运行以下命令：
kubectl apply -f sa-frontend-deployment-green.yaml --record deployment "sa-frontend" configured
使用以下命令检查系统状态：
kubectl rollout status deployment sa-frontend Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 of 2 updated replicas are available... deployment "sa-frontend" successfully rolled out
根据响应此命令而显示的数据，我们可以得出结论，更新部署成功。 在升级过程中，旧副本一次被替换为新副本。 , , , . , , .
, , :
minikube service sa-frontend-lb
, .
, , — .
RollingUpdate
,
kubectl apply -f sa-frontend-deployment-green.yaml --record , Kubernetes , , . , ,
rinormaloku/sentiment-analysis-frontend:green . , , .
RollingUpdate , ,
maxUnavailable: 1 maxSurge: 1 . , Deployment , , , . , , , .
Deployment. , . .
▍
, , . «! ! !», — . . , , :
kubectl rollout history deployment sa-frontend deployments "sa-frontend" REVISION CHANGE-CAUSE 1 <none> 2 kubectl.exe apply --filename=sa-frontend-deployment-green.yaml --record=true
: «, , ?».
«. , ?», — .
, , :
kubectl rollout undo deployment sa-frontend --to-revision=1 deployment "sa-frontend" rolled back
. , .
.
.
!
, . Kubernetes , , . , !
. , .
CHANGE-CAUSE <none> , —
kubectl.exe apply –filename=sa-frontend-deployment-green.yaml –record=true ?
, --
record , .
, , , .
Kubernetes:
Kubernetes, , . , .
.
▍ sa-logic
resource-manifests :
kubectl apply -f sa-logic-deployment.yaml --record deployment "sa-logic" created
sa-logic . Python-.
app: sa-logic .
sa-logic , .
sa-logic-deployment.yaml .
-, , —
sa-logic .
▍ sa-logic
, Service. , Java-,
sa-webapp , , Python-. , , , Python-, . , , , .
, , , , . ,
sa-logic ,
sa-logic .
:
kubectl apply -f service-sa-logic.yaml service "sa-logic" created
, .
sa-logic ,
sa-webapp , , .
sa-webapp .
▍ sa-webapp
, Deployment - . ,
sa-web-app-deployment.yaml , :
- image: rinormaloku/sentiment-analysis-web-app imagePullPolicy: Always name: sa-web-app env: - name: SA_LOGIC_API_URL value: "http://sa-logic" ports: - containerPort: 8080
env ? , , ,
SA_LOGIC_API_URL http://sa-logic . , , . ?
kube-dns.
▍DNS- Kubernetes
Kubernetes ,
kube-dns . DNS-.
kube-dns , DNS- .
,
sa-logic , IP-.
kube-dns IP- .
http://sa-logic IP-.
Deployment
sa-webapp .
▍ sa-webapp
:
kubectl apply -f sa-web-app-deployment.yaml --record deployment "sa-web-app" created
sa-webapp , . React- ,
sa-webapp .
▍ sa-webapp
service-sa-web-app-lb.yaml , , , , . , , :
kubectl apply -f service-sa-web-app-lb.yaml service "sa-web-app-lb" created
. , , . ,
sa-frontend , Java-
sa-webapp ,
http://localhost:8080/sentiment . , ,
sa-webapp , React- , Java-.
, . , — , , .
, :
- IP-
sa-webapp , :
minikube service list
|-------------|----------------------|-----------------------------|
| NAMESPACE | NAME | URL |
|-------------|----------------------|-----------------------------|
| default | kubernetes | No node port |
| default | sa-frontend-lb | http://192.168.99.100:30708 |
| default | sa-logic | No node port |
| default | sa-web-app-lb | http://192.168.99.100:31691 |
| kube-system | kube-dns | No node port |
| kube-system | kubernetes-dashboard | http://192.168.99.100:30000 |
|-------------|----------------------|-----------------------------| - IP-
sa-frontend/src/App.js . , :
analyzeSentence() { fetch('http://192.168.99.100:31691/sentiment', { /* */}) .then(response => response.json()) .then(data => this.setState(data)); }
- React-,
sa-frontend npm run build . - :
docker build -f Dockerfile -t $DOCKER_USER_ID/sentiment-analysis-frontend:minikube.
- Docker Hub:
docker push $DOCKER_USER_ID/sentiment-analysis-frontend:minikube
sa-frontend-deployment.yaml , .- :
kubectl apply -f sa-frontend-deployment.yaml
, , , ,
minikube service sa-frontend-lb . , - .
总结
Kubernetes , , , , . Kubernetes , , . Kubernetes Supernetes.
, :
- , , React, Java Python.
- Docker, ,
Dockerfile . - , , Docker Hub.
, Kubernetes:
, , Kubernetes.
亲爱的读者们！ Kubernetes?
