库伯内特斯的“endpoint”是什么？
我是Kubernetes的新手，开始阅读文档。通常使用“endpoint”一词，但文档中缺乏明确的定义。
Kubernetes的“终点”是什么？它位于哪里？
我可以想象“endpoint”是单个“节点”的某种接入点，但这只是猜测。
共有3个答案
endpoint是一种资源，它获取动态分配给它的一个或多个pod的IP地址以及端口。可以使用kubectl get endpoint查看endpoint。
kubernetes服务引用endpoint资源，因此该服务具有POD内部IP的记录，以便能够与POD通信。
我们需要endpoint作为抽象层，因为kubernetes中的“服务”作为编排的一部分，以确保将流量分配给POD（包括仅将流量发送给健康的POD）。例如，如果一个pod死亡，将生成一个具有新IP地址的替换pod。从概念上讲，将从endpoint对象中删除死吊舱IP，并添加新创建吊舱的IP，以便更新服务并“知道”要连接到哪个吊舱。
阅读“将POD公开到集群”，然后在此处阅读“创建服务”—https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/#exposing-到群集的吊舱
调查和了解这种关系的一个简单方法是：
kubectl描述pods-并观察pods的IP地址kubectl获取ep-并观察分配给您的endpoint的IP地址kubectl描述服务myServiceName-并观察与您的服务关联的endpoint
因此，endpoint与单个节点的IP无关。我发现了解kubernetes的总体结构以及集群、节点、服务、endpoint和POD之间的关系很有用。此图很好地总结了它，并显示了导致OSI第2层（TCP层）到达后端节点1的入口流，而OSI第7层（http层）入口最终到达Pod 1中的“Web容器1”：
POD通过endpoint向服务公开自己。如果你是豆荚的一部分。
虽然在术语表中确实没有endpoint条目，但这是一个定义良好的Kubernetes网络概念或抽象。因为它是次要的，你通常不会直接操纵它。定义了一个核心资源endpoint，命令行也支持该endpoint：
$ kubectl get endpoints
NAME ENDPOINTS AGE
kubernetes 192.168.64.13:8443 10d
在这里，您可以看到它实际上是什么：一个IP地址和一个端口。通常，您会让服务管理endpoint（服务将流量路由到每个pod一个EP），但如果您有需要的用例，您也可以手动管理它们。
-
我只是想知道如何手动设置库伯内特斯Web仪表板使用的外部endpoint。 创建名称空间kube系统后，我运行了以下操作： 是否有一个标志可以用来指定外部访问使用哪个tcp端口？据我所知，这只是随机分配一个。我已经查看了留档，但我很难找到解决方案。如果有任何帮助，将不胜感激。
-
我假设没有愚蠢的问题，所以这里有一个我找不到直接答案的问题。 现在的情况 我目前有一个运行1.15的Kubernetes集群。AKS上的x，通过Terraform部署和管理。AKS最近宣布Azure将在AKS上停用Kubernetes的1.15版本，我需要将集群升级到1.16或更高版本。现在，据我所知，直接在Azure中升级集群不会对集群的内容产生任何影响，即节点、豆荚、秘密和当前在那里的所有其他
-
null
-
我在Kubernetes是个新手。我想知道在kubernetes环境中最好的生产部署场景是什么。 在过去的学派中，我习惯于将Web服务器（例如Nginx或Apache）放在DMZ层，而将其放在其他层（我们称之为层）。这样，只有web服务器在DMZ上，恶意攻击只能在web服务器VM上进行。 据我所知，K8S部署不再需要这种方法；这是因为K8S自己处理网络、吊舱和流量。所以我在考虑最确定的部署方案。
-
我已经在Kubernetes上部署了Prometheus，并提供了配置文件作为配置映射资源。该文件作为卷装入普罗米修斯吊舱中。 在集群中更改配置映射后，我用一个空POST请求点击Prometheus服务器endpoint，以便重新加载它（如文档中所述） 然而，当我对配置映射进行更改并重新部署它时，我会经历大约30秒的“滞后”，直到prometheus.yml文件在pod中更新。 我在这里读到，这是
-
据我所知，作业对象应该在一定时间后收获豆荚。但是在我的GKE集群（库伯内特斯1.1.8）上，“kubectl get pods-a”似乎可以列出几天前的豆荚。 所有这些都是使用乔布斯API创建的。 我确实注意到在使用 kubectl 删除作业后，pod 也被删除了。 我在这里主要担心的是，我将在批量作业中在集群上运行成千上万个pod，并且不想让内部待办系统过载。