port配置
踩坑完毕，回到主线。
前面关于port的理解存在偏差，需要用实验来确认port配置的含义。
k8s官方文档对于对于这些配置项的解释还是没有很完善。下面是在其他博文中找到的解释。
ports: #需要暴露的端口库号列表
- name: string #端口号名称
containerPort: int #容器需要监听的端口号
hostPort: int #容器所在主机需要监听的端口号，默认与ContainerPort相同
protocol: string #端口协议，支持TCP和UDP，默认TCP
已知：
从k8s集群内部的宿主机（物理机、虚拟机）可以直接访问pod的服务地址 ip:80
未知（需要测试）：
1、同一局域网内，但没有加入k8s集群的其他服务器能否访问pod的服务地址 ip:80---无法访问
2、能否跳过pod直接访问容器的服务地址 ip:80---没查到ip
首先要知道容器的IP地址
[root@devhost25-2 ~]# docker inspect --format='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(docker ps -aq) |grep nginx
/k8s_nginx_mynginx4_default_8bd68b04-cae2-4d35-abf6-bc425c54aa64_0 -
/k8s_POD_mynginx4_default_8bd68b04-cae2-4d35-abf6-bc425c54aa64_0 -
/k8s_nginx_mynginx_default_5653595e-9763-4a7b-b3f8-210bad3daa26_0 -
/k8s_POD_mynginx_default_5653595e-9763-4a7b-b3f8-210bad3daa26_0 -
可以看到上面的命令查出的结果是 - 无法看出ip，尝试进入容器查看
# ip addr
/bin/sh: 22: ip: not found
# ifconfig
/bin/sh: 23: ifconfig: not found
然后我就没辙了，不过根据linux系统的精神，所有内容都是文件，但是我google了好久也没找到ip地址到底存在哪一个文件中。然后我就怀疑是不是一定要容器开放端口，ip地址才可以用docker inspect查询，起了一个不开端口的容器，结果也是有ip的。后来问了一个底层开发的朋友，据说ip是不写文件的。
[root@md-2 ~]# docker inspect --format='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(docker ps -aq)
/myubuntu - 172.17.0.2
那只能先认为通过k8s启动的容器其实是没有容器ip的。
从侧面看，也很有可能k8s启动的容器确实没有ip
-从容器与pod的关系，一个pod内部可以有多个容器，这些容器之间共享资源
-flannel calico的原理介绍中，终端都只是到了pod，而没有体机容器
3、访问pod所在的主机的80端口能否返回相同的响应---无法访问
-果然端口都没有，确实无法访问
[root@devhost25-2 ~]# curl 10.100.1.237
curl: (7) Failed to connect to 10.100.1.237 port 80: Connection refused
从以上的信息来看，这个port配置应该和docker中暴露端口的意思是一样的，例如下面的例子
docker run -p 80:80
来做一下实验：
在我们之前的pod配置文件上增加配置，如下
apiVersion: v1 #必选，版本号，例如v1
kind: Pod #必选，Pod
metadata: #必选，元数据
name: mynginx #必选，Pod名称----name1
labels: #自定义标签
name: mynginx #自定义标签名字----name2
app: mynginx
annotations: #自定义注释
name: mynginx #自定义注释名字----name3
app: mynginx
spec: #必选，Pod中容器的详细定义
containers: #必选，Pod中容器列表
- name: nginx #必选，容器名称----name4
image: nginx:1.20.0 #必选，容器的镜像名称
ports:
- name: http #端口号名称
containerPort: 80 #容器端口
hostPort: 80 #pod对应的端口
protocol: TCP #协议类型
结果和我们之前的猜测保持一致，增加ports的配置之后，访问宿主机的ip:80也可以访问到pod的内容了。
我这里pod ip 是 10.19.130.67，宿主机是 10.100.1.237。curl 10.19.130.67 和 curl 10.100.1.237 得到的结果是一样的。正当我想再仔细看看的时候，服务器又挂了，wc，只能明天找网管重启了。
---第二天
昨天，我还想看看
1、关了这个pod之后是否就不能访问了
启动了2个pod如下，mynginx1没有配置ports，mynginx2配置了ports。
[root@brdev1 matt]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mynginx1 1/1 Running 1 23h 10.19.130.68 devhost25-2 <none> <none>
mynginx2 1/1 Running 1 23h 10.19.130.69 devhost25-2 <none> <none>
当我关了pod-mynginx2之后访问宿主机10.100.2.167应该就不能通了，结果居然是---能访问到！
大吃一惊！结果ip弄错了，宿主机不是10.100.2.167，而是10.100.1.237，犯了个低级错误。
结果如下：这回和预期的结果终于一样了。
[root@brdev1 matt]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mynginx1 1/1 Running 0 13s 10.19.130.70 devhost25-2 <none> <none>
mynginx2 1/1 Running 0 7s 10.19.130.71 devhost25-2 <none> <none>
[root@brdev1 matt]# curl 10.19.130.70
<!DOCTYPE html>
<html>
...
</html>
[root@brdev1 matt]# curl 10.19.130.71
<!DOCTYPE html>
<html>
...
</html>
[root@brdev1 matt]# curl 10.100.1.237
<!DOCTYPE html>
<html>
...
</html>
[root@brdev1 matt]# kubectl delete pod mynginx2
pod "mynginx2" deleted
[root@brdev1 matt]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mynginx1 1/1 Running 0 3m43s 10.19.130.70 devhost25-2 <none> <none>
[root@brdev1 matt]# curl 10.19.130.70
<!DOCTYPE html>
<html>
...
</html>
[root@brdev1 matt]# curl 10.19.130.71
^C #无响应
[root@brdev1 matt]# curl 10.100.1.237
curl: (7) Failed connect to 10.100.1.237:80; 拒绝连接
2、宿主机上是不是本身就开启了nginx，所以恰巧就能访问
确认宿主机上没有开启nginx
3、宿主机上的端口开放情况
使用netstat查看宿主机的端口开放，居然没有发现80端口开着，好奇怪。
[root@devhost25-2 ~]# netstat -ltpne |grep 80
tcp6 0 0 10.100.1.237:41280 :::* LISTEN 0 840891 24698/java
那如果在10.100.1.237宿主机上启动一个nginx端口开在80，结果会是什么样子呢。
我居然启动了，没有端口已被占用的报错。现在把宿主机上的nginx的index页面的内容改一下，看访问10.100.1.237:80时，到底访问的是哪一个nginx。
分别从集群内部3台服务器和集群外部1台服务器的机器取访问10.100.1.237:80，访问到的都是pod中的nginx。
会不会跟启动顺序有关，因为现在的情况是先启动了pod-nignx，后启动 宿主机-nginx，那现在将pod-nginx关闭，访问10.100.1.237:80，看是啥。
集群内部3台服务器和集群外部1台服务器访问10.100.1.237:80，结果一致，都是宿主机-nginx。
再启动pod-nginx，查看结果。
访问结果又变回pod-nginx了，4台服务器结果一致。
再去看一下宿主机-nginx的日志，有没有报错信息-----------没有错误日志
现在基本可以得出结论了：当pod和宿主机同时使用某一个端口时，不会因为冲突而报错，但是pod会优先占用端口，而与启动顺序无关。
至于为什么会这样，就不去深究了，毕竟精力有限，作为运维实施，了解到这样子的程度应该够用了。
