Kubernetes Services概述
(凡人皆有一死来描述pod,没有比这跟准确的了)。事实上,Pod是有生命周期的。当一个工作节点(Node)销毁时,节点上运行的Pod也会销毁,然后通过ReplicationController动态创建新的Pods来保持应用的运行。作为另一个例子,考虑一个图片处理 backend,它运行了3个副本,这些副本是可互换的 —— 前端不需要关心它们调用了哪个 backend 副本。也就是说,Kubernetes集群中的每个Pod都有一个独立的IP地址,甚至是同一个节点上的Pod,因此需要有一种方式来自动协调各个Pod之间的变化,以便应用能够持续运行。
Enter Services。Kubernetes中的Service 是一个抽象的概念,它定义了Pod的逻辑分组和一种可以访问它们的策略,这组Pod能被Service访问,使用YAML (优先)或JSON 来定义Service,Service所针对的一组Pod通常由LabelSelector实现(参见下文,为什么可能需要没有 selector 的 Service)。
可以通过type在ServiceSpec中指定一个需要的类型的 Service,Service的四种type:
- ClusterIP(默认) - 在集群中内部IP上暴露服务。此类型使Service只能从群集中访问。
- NodePort - 通过每个 Node 上的 IP 和静态端口(NodePort)暴露服务。NodePort 服务会路由到 ClusterIP 服务,这个 ClusterIP 服务会自动创建。通过请求 <NodeIP>:<NodePort>,可以从集群的外部访问一个 NodePort 服务。
- LoadBalancer - 使用云提供商的负载均衡器(如果支持),可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。
- ExternalName - 通过返回
CNAME
和它的值,可以将服务映射到externalName
字段的内容,没有任何类型代理被创建。这种类型需要v1.7版本或更高版本kube-dnsc
才支持。
更多不同类型Service的信息,请参考“Using Source IP”教程,Connecting Applications with Services。
使用ExternalName类型可以实现一种情况,在创建Service涉及未定义selector
的示例,创建的Service selector
不创建相应的Endpoints对象,可以通过手动将Service映射到特定Endpoints。
Kubernetes Service 是一个抽象层,它定义了一组逻辑的Pods,借助Service,应用可以方便的实现服务发现与负载均衡。
Services和Labels
如上图,A中Service 路由一组Pods的流量。Service允许pod在Kubernetes中被销毁并复制pod而不影响应用。相关Pod之间的发现和路由(如应用中的前端和后端组件)由Kubernetes Services处理。
Service 使用label selectors来匹配一组Pod,允许对Kubernetes中的对象进行逻辑运算,Label以key/value 键/值对附加到对象上。以多种方式使用:
- 指定用于开发,测试和生产的对象
- 嵌入版本Label
- 使用Label分类对象
你可以在使用
--expose
kubectl 创建 Deployment 的同时创建 Service 。
Label可以在创建时或以后附加到对象上,可以随时修改。
下一步:使用在线互动教程
service这部分需要重新校对,翻译的稀烂,就算意译可以把原来表达内容的逻辑线理清楚把,用词格式消除歧义,修正花的时间是不是都不如读原版部分去理解呢?
https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/
Kubernetes中的Service是一个抽象概念,定义了一系列有逻辑关系的Pods,以及一种访问它们的策略。Service使得有相互依赖关系的Pods之间可以建立一种松散的连接
…
ClusterIP 在集群内部IP上暴露服务,这类服务只有集群内可以访问
这里显然是配合着机翻的
I’ve been troubled for several days with this topic. slotsite, But by chance looking at your post solved my problem! I will leave my blog, so when would you like to visit it?