为什么"kubectl get"的 YAML 与 GKE 中"kubectl apply"的 YAML 如此不同？

Question

我有一个GKE集群。

我使用kubectl apply从我的本地机器应用以下YAML:

apiVersion: v1
kind: Service
metadata:
name: flask-app-svc
namespace: myapp
spec:
ports:
- port: 5000
targetPort: 5000
selector:
component: flask-app

得到应用。所有的好。✅

---

然后使用kubectl get service从集群中获取YAML。它返回如下:

apiVersion: v1
kind: Service
metadata:
annotations:
cloud.google.com/neg: '{"ingress":true}'
cloud.google.com/neg-status: '{"network_endpoint_groups":{"5000":"k8s1-5fe0c3c1-myapp-flask-app-svc-5000-837dba94"},"zones":["asia-southeast1-a"]}'
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"flask-app-svc","namespace":"myapp"},"spec":{"ports":[{"port":5000,"targetPort":5000}],"selector":{"component":"flask-app"}}}
creationTimestamp: "2021-10-29T14:40:49Z"
name: flask-app-svc
namespace: myapp
resourceVersion: "242820340"
uid: ad80f634-5aab-4147-8f71-11ccc44fd867
spec:
clusterIP: 10.22.52.180
clusterIPs:
- 10.22.52.180
ports:
- port: 5000
protocol: TCP
targetPort: 5000
selector:
component: flask-app
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}

---

1。kubernetes的概念是什么?在玩什么?

2。为什么这两个yaml彼此如此不同?

3。幕后发生了什么?

4。这是GKE特有的吗，还是任何k8s集群都有这种行为?

5。我在哪里可以找到一些信息/文章来了解更多关于这个概念?

---

提前感谢。

我已经想了一段时间了。感谢您在此提供的任何帮助和建议。

Answer 1

Kubernetes API服务器验证和配置API对象的数据，这些对象包括pod、服务、复制控制器和其他。API Server为REST操作提供服务，并提供集群共享状态的前端，所有其他组件通过该前端进行交互。API服务器使用用户提供的定义来创建创建所需对象所需的所有详细定义。在本文档中，您可以找到GKE API服务器引擎的概述。

您可以在本文档中找到关于创建操作的示例。在那里，您可以在请求输入和为API服务器生成的响应之间切换，以创建所需对象的完整定义，其参数，元数据和所有相关配置参数，您可以在"extended"中看到。原始yaml文件的版本。在同一文档中，您可以找到有关此主题的其他信息。

Answer 2

GKE中的服务是向预期的最终用户公开那些在一组pod中运行的应用程序的一种方式。所有这些元素构成了GKE集群的一部分。如果您应用YAML来创建服务，那么为了让您的用户可以访问应用程序，还需要一些额外的东西。kubernetes和GKE的特性之一是自动创建、设置和维护所需的资源，例如在本例中创建服务。GKE所做的所有额外设置和定义都记录在YAML文件中。

如果您想了解更多关于这个概念的信息，您可以从Google Kubernetes Engine产品页面开始，或者在同一页面中查阅GKE文档。另一个好的起点是阅读这个GKE概述。