目录
通过 Pod IP 访问应用
通过 ClusterIP Service 在集群内部访问
通过之前的操作, 应用部署完成了, 我们的 Demo 网站已经成功启动了, 那么如何访问网站呢?
通过 Pod IP 访问应用
我们可以通过 Pod IP 来访问之前部署的网站, 但是前提是我们需要知道 Pod IP. 我们可以通过 "kubectl get" 命令的参数 "-o wide" 来输出相关的信息, 比如 Pod IP:
kubectl get pods -lapp=demo -o wide
如果网络是通畅的, 那么我们可以在任意的节点上访问我们的应用, 如:
curl --head http://10.0.2.12
我们使用 curl 以 get 方式请求 demo 应用, 返回请求头为 200, 那么表示我们已经成功访问了 Demo. 如果你还不太相信, 我们可以通过安装了 UI 界面的 CentOS 节点服务器的浏览器上访问这些 Pod IP, 如下所示:
虽然我们通过 Pod IP 成功的访问到了应用, 但是 Pod 有生老病死, 如果 "死" 了呢, 我们如何访问? Deployment 会重建么? 我们来试一试:
- kubectl delete pods -lapp=demo
- kubectl get pods -lapp=demo -o wide
很不幸的是, 如上图所示, POD IP 变掉了. 那么意味着 POD IP 会随着 POD 的生老病死而发生变化. 而且, 不仅存在这个问题, 如果我们直接使用 POD IP, 那么多个 POD 也变得毫无意义. 那么我们应该到底如何来访问我们的应用呢?
通过 ClusterIP Service 在集群内部访问
Kubernetes 服务 (Service) 就是为此而抽象出来的, 为了让应用能够稳定的输出, Service 应运而生.
Service 在 Kubernetes 中是一个抽象的概念, 它定义了一组逻辑上的 Pod 和一个访问它们的策略 (通常称之为微服务).Service 是通过标签选择器来绑定一组 Pod 的 Endpoints(端点) 对象, 当 Pod 的 IP 发生变化, Endpoints 也随之变化. 当 Service 接受到请求时, 就能通过 EndPoints 找到请求转发的目标 Pod 地址. 也就是说, 通常情况下, Service 定义了集群 IP 和端口, EndPoints 则维护了一组 Pod IP 和端口.
了解了这些, 接下来我们就使用 ClusterIP Service 来访问刚才的 Demo 应用.
ClusterIP Service 是默认的 Service 类型, 其通过集群的内部 IP 暴露服务, 因此仅能在集群内部访问, 常用于数据库等应用.
这里, 我们定义一个简单的 Service 集群 IP 配置:
- apiVersion: v1
- kind: Service #资源类型
- metadata: #标准元数据
- name: demo-service #服务名称
- spec: #规范定义
- type: ClusterIP #服务类型, 不填写此字段则默认为 ClusterIP 类型, 也就是集群 IP 类型
- selector: #标签选择器
- App: demo #标签
- ports: #端口
- - protocol: TCP #协议, 能够支持 TCP 和 UDP
- port: 80 #当前端口
- targetPort: 80 #目标端口
接下来, 我们来执行 Service 的创建并且分别查询了 Service 和 Endpoints:
- kubectl create -f clusterIPService.YAML
- kubectl get services demo-service -o wide
- kubectl get endpoints demo-service -o wide
如上图所示, 我们创建了集群 IP 为 "11.13.47.67" 的 Service, 端口为 80(通常情况下, 我们将 port 和 targetPort 设置为相同的值). 同时我们通过 Endpoints 列表看到, Endpoints 自动绑定了 5 个 Pod IP. 接下来我们试试在集群内 (节点上) 访问:
注意: 如果我们需要在创建时设置 Service 固定 IP 该如何去设置呢? 可以通过字段 "spec.clusterIp" 进行设置, 值需要符合 Service IP 段要求.
浏览器非常完美的呈现了 Demo. 在集群内是可以访问了, 如果我们提供对外服务呢? 比如我们希望我们的 Demo 被其他电脑访问, 以获得用户的赞赏, 老板的好评, 那么该如何处理呢? 我们下一篇再来分析!
往期内容链接
Docker+ Kubernetes 已成为云计算的主流(二十五)
容器化之后如何节省云端成本?(二十六)
了解 Kubernetes 主体架构(二十七)
使用 Minikube 部署本地 Kubernetes 集群(二十八)
使用 kubectl 管理 k8s 集群(二十九)
使用 Kubeadm 创建 k8s 集群之部署规划(三十)
使用 Kubeadm 创建 k8s 集群之节点部署(三十一)
集群故障处理之处理思路以及健康状态检查(三十二)
集群故障处理之处理思路以及听诊三板斧(三十三)
开源导入导出通用库 Magicodes.ExporterAndImporter 发布
使用 Kubectl 部署应用
来源: https://www.cnblogs.com/codelove/p/11506881.html