标签：c中 流程 aml 访问者 net curl 查看 mysq 好的
service
为了适应快速的业务需求，微服务架构已经逐渐成为主流，微服务架构的应用需要有非常好的服务编排支持，kubernetes自身就有一套简化的服务代理和发现的机制，天然适应微服务架构
原理：
在kubernetes中，在收到rc调控的时候，pod副本数是变化的，对应的虚IP也是变化的，比如发生迁移或者伸缩时。这对于pod的访问来说是不能接受的，kubernetes中的service是一种逻辑概念。它定义了一个pod逻辑集合以及访问它们的策略，service与pod的关联同样是通过label完成的。service的目标是提供一种桥梁，他会为访问者提供一个固定的访问IP地址，用于在访问时重定向到相应的后端，这可以使一些非kubernetes原生应用程序，在无需为kubernetes编写特定代码的前提下轻松访问后端。
[root@k8s_master ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE mysql-rc-2j1nf 1/1 Running 0 2h 200.1.70.3 10.0.0.31 mysql-rc-4xvx3 1/1 Running 0 10s 200.1.68.4 10.0.0.30 #重启拉起的pod的IP地址200.1.68.4 mysql-rc-fb9l8 1/1 Terminating 2 11d 200.1.68.3 10.0.0.30 #把这个pod删除以后，原IP地址200.1.68.3 myweb-1brwl 1/1 Running 0 2h 200.1.68.5 10.0.0.30
kubernetes中的IP地址：
正是因为有了这三个IP地址，才能使某个部署在容器上的应用被访问，大致流程是：某个nginx业务，部署在3个pod上以实现负载均衡，三个pod受控于RC，但是pod构建或删除经导致IP地址变化，因为有了3个pod的cluster IP，该IP地址是固定的。通过label在标识容器，容器也会主动加入clusterIP中，另一方面，clusterIP与nodeIP地址有相应的映射关系，即外部通过访问node IP的某一特定端口，映射到cluster IP后，cluster在负载到某一个节点，这样实现业务访问。
# Address range to use for services #apiserver中默认的cluster IP地址范围 KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
创建SVC
[root@k8s_master k8s_pod_yml]# cat myweb-svc.yaml apiVersion: v1 kind: Service #服务类型为service metadata: name: myweb-svc #这个名字仅仅是SVC的名字 spec: type: NodePort #类型为NodePort，这样的话，下面的nodeport不指定就会从30000-32767随机分配一个 ports: - port: 80 #pod的端口 nodePort: 31111 #node的端口 selector: app: myweb #这个就决定了svc控制哪些pod
查看SVC详情：
[root@k8s_master k8s_pod_yml]# kubectl describe svc myweb-svc Name: myweb-svc Namespace: default Labels: <none> Selector: app=myweb #表示SVC对应的后端pod的标签 Type: NodePort IP: 10.254.252.72 #cluster IP地址， Port: <unset> 80/TCP NodePort: <unset> 31111/TCP Endpoints: 200.1.68.2:80,200.1.70.2:80 #目前注册到SVC的pod Session Affinity: None No events.
如果此时出现负载高的情况，修改rc的副本数以后，发现新pod会自动注册到svc中。该功能就保证了以后即使pod迁移、重建导致pod IP地址变化后，会自动向SVC注册，对用户没任务影响
[root@k8s_master k8s_pod_yml]# kubectl describe svc myweb-svc Name: myweb-svc Namespace: default Labels: <none> Selector: app=myweb Type: NodePort IP: 10.254.252.72 Port: <unset> 80/TCP NodePort: <unset> 31111/TCP Endpoints: 200.1.68.2:80,200.1.68.3:80,200.1.70.2:80 #修改rc副本数为3 Session Affinity: None No events.
[root@k8s_master k8s_pod_yml]# curl -I 10.0.0.31:31111 #这样就可以通过访问node IP的某一端口访问pod服务了 HTTP/1.1 200 OK Server: nginx/1.19.6 Date: Sun, 10 Jan 2021 06:18:43 GMT Content-Type: text/html Content-Length: 612 Last-Modified: Tue, 15 Dec 2020 13:59:38 GMT Connection: keep-alive ETag: "5fd8c14a-264" Accept-Ranges: bytes
查看node节点上的端口情况，发现kube-proxy进程占用了相应的31111端口。即使只有一个pod，在两个node上的31111端口都会被占用。这个端口信息会保存在etcd数据库中
[root@k8s_node_1 ~]# netstat -tlunp | grep 1111 tcp6 0 0 :::31111 :::* LISTEN 16211/kube-proxy
rc控制器保证了容器的存活，service保证了业务能够被外部访问。这样部署在容器上的业务就能正常工作了，下次学习一下更高级的部署工具---deployment
标签：c中 流程 aml 访问者 net curl 查看 mysq 好的
原文地址：https://www.cnblogs.com/woshinidaye123/p/14258382.html
