在master节点执行
bash
kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --port=80 --type=NodePort1. kubectl create deployment nginx --image=nginx
命令解析
bash
kubectl create deployment nginx --image=nginxkubectl：Kubernetes 的命令行工具，用于管理 Kubernetes 集群。create：创建一个新的资源。deployment：指定要创建的资源类型为Deployment。Deployment是 Kubernetes 中的一种控制器，用于管理无状态应用的 Pod 的生命周期，确保指定数量的 Pod 始终处于运行状态。nginx：这是Deployment的名称，你可以根据需要自定义。--image=nginx：指定 Pod 中容器使用的镜像。这里使用的是官方的nginx镜像。
具体行为
-
创建一个
Deployment：- Kubernetes 会创建一个名为
nginx的Deployment。 - 这个
Deployment会启动一个 Pod，该 Pod 中运行一个容器，使用nginx镜像。 - 默认情况下，
Deployment会确保始终有一个 Pod 在运行。
- Kubernetes 会创建一个名为
-
Pod 的配置：
- Pod 的名称会自动生成，类似于
nginx-<随机字符串>。 - Pod 中的容器会监听默认的
nginx端口（通常是80）。
- Pod 的名称会自动生成，类似于
-
结果：
-
你可以通过以下命令查看创建的
Deployment和 Pod：bashkubectl get deployment kubectl get pods
-
2. kubectl expose deployment nginx --port=80 --type=NodePort
命令解析
bash
kubectl expose deployment nginx --port=80 --type=NodePortkubectl：Kubernetes 的命令行工具。expose：将现有的资源（如Deployment或Pod）暴露为一个服务。deployment nginx：指定要暴露的资源是名为nginx的Deployment。--port=80：指定 Pod 内部容器监听的端口。这里指定为80，因为nginx容器默认监听80端口。--type=NodePort：指定服务的类型为NodePort。NodePort类型的服务会在集群的每个节点上开放一个端口（通常是高端口，如30000-32767），并将请求转发到 Pod 的指定端口。
具体行为
-
创建一个
Service：- Kubernetes 会创建一个名为
nginx的Service，类型为NodePort。 - 这个
Service会将集群中某个节点的某个端口（NodePort）映射到 Pod 的80端口。
- Kubernetes 会创建一个名为
-
端口映射：
-
Kubernetes 会自动分配一个
NodePort（通常是30000-32767范围内的端口）。 -
你可以通过以下命令查看分配的
NodePort：bashkubectl get service nginx -
输出示例：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx NodePort 10.106.223.10 <none> 80:31570/TCP 11m在这个例子中，
NodePort被分配为31570。
-
-
访问服务：
-
你可以通过集群中任何一个节点的 IP 地址加上
NodePort来访问服务。例如：bashcurl <节点IP>:31570 -
Kubernetes 的网络代理（如
kube-proxy）会捕获这个请求，并将其转发到某个运行nginx的 Pod 的80端口。
-
总结
-
kubectl create deployment nginx --image=nginx：- 创建一个名为
nginx的Deployment，启动一个 Pod，Pod 中运行一个使用nginx镜像的容器。
- 创建一个名为
-
kubectl expose deployment nginx --port=80 --type=NodePort：- 将
nginxDeployment暴露为一个NodePort类型的服务。 - 创建一个
Service，将集群中某个节点的某个端口（NodePort）映射到 Pod 的80端口。 - 你可以通过集群中任何一个节点的 IP 地址加上
NodePort来访问服务。
- 将
验证
可以通过以下命令验证整个过程：
-
查看
Deployment和 Pod：bashkubectl get deployment kubectl get pods -
查看
Service：bashkubectl get service nginx -
访问服务：
bashcurl <节点IP>:<NodePort>
-
可以通过
kubectl get svc,pod观察nginx状态：chenaws@k8smaster:~$ kubectl get svc,pod
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 15d
service/myhello-svc NodePort 10.110.50.145 <none> 80:30000/TCP 15d
service/nginx NodePort 10.106.223.10 <none> 80:31570/TCP 49mNAME READY STATUS RESTARTS AGE
pod/myhello-rc-5j2l5 1/1 Running 5 (72m ago) 15d
pod/myhello-rc-989q7 1/1 Running 5 (72m ago) 15d
pod/myhello-rc-bc8pz 1/1 Running 5 (72m ago) 15d
pod/myhello-rc-cv58k 1/1 Running 5 (72m ago) 15d
pod/myhello-rc-r8lgx 1/1 Running 5 (72m ago) 15d
pod/nginx-8f458dc5b-vt2sd 1/1 Running 0 50m
chenaws@k8smaster:~$
实际使用时如果发现nginx节点服务迟迟没有running，可以通过describe观察pod状态
-
使用：
kubectl describe pod nginx-8f458dc5b-vt2sd
主要查看Events 是否有报错，如果卡在pulling ，可以尝试到对应节点重新
docker pull nginx -
如何查看pod被分配到哪个节点？
后续可以在集群任意节点访问集群内任意节点ip的
31570端口来访问133这个节点的nginx服务
为什么是31570端口？
1. 端口映射关系
在 Kubernetes 中，NodePort 类型的服务会将集群中的某个端口（通常是高端口，如 30000-32767）映射到 Pod 的内部端口。具体来说：
nginx服务 ：- ClusterIP ：
10.106.223.10（仅在集群内部可访问） - NodePort ：
31570（在集群的每个节点上都可以通过这个端口访问服务） - 目标端口 ：
80（Pod 内部的 Nginx 服务监听的端口）
- ClusterIP ：
这意味着，无论你访问集群中哪个节点的 31570 端口，Kubernetes 都会将请求转发到某个运行 Nginx 的 Pod 的 80 端口。
2. 为什么可以访问三个 IP 地址
我的 Kubernetes 集群有三个节点（192.168.132.131、192.168.132.132、192.168.132.133）。因为 nginx 服务的类型是 NodePort，所以可以通过任何一个节点的 31570 端口访问 Nginx 服务。
3. 访问这个端口时发生了什么
当通过 curl 192.168.132.131:31570 发起请求时：
- 请求到达节点 ：请求发送到集群中的一个节点（比如
192.168.132.131）的31570端口。 - Kubernetes 服务代理 ：Kubernetes 的网络代理（如 kube-proxy）会捕获这个请求，并根据服务的定义（
nginx服务）将请求转发到192.168.132.133这个运行 Nginx 的 Pod。 - Pod 处理请求 ：请求被转发到 Nginx Pod 的
80端口，由 Nginx 服务器处理。 - 返回响应：Nginx 服务器处理完请求后，将响应返回给 kube-proxy，kube-proxy 再将响应返回给客户端。
4. 验证和总结
- 端口映射 ：
31570端口是 Kubernetes 为nginx服务分配的外部访问端口，它会将请求转发到 Pod 的80端口。 - 多节点访问 ：因为
NodePort服务在集群的每个节点上都暴露了相同的端口，所以你可以通过任何一个节点的 IP 地址加上31570端口来访问服务。 - 负载均衡：Kubernetes 会自动选择一个运行 Nginx 的 Pod 来处理请求，实现了简单的负载均衡。
如何实现work节点使用kubectl
- 刚配置完k8s时，如果在work节点执行，会报错
- 我们可以通过执行以下命令实现work使用kubectl
shell
# 1.将master节点中/etc/kubernetes/admin.conf拷贝到要运行的work节点服务器，/etc/kubernetes目录中，使用：
# 注意 chenaws是要拷贝的机器的用户名，@后是主机名
scp /etc/kubernetes/admin.conf chenaws@k8snode2:/etc/kubernetes
# 2.在对应拷贝到的服务器上配置环境变量：
echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile
source ~/.bash_profile-
使用
scp /etc/kubernetes/admin.conf chenaws@k8snode2:/etc/kubernetes传输时，要求要在root模式， -
也可以用下面这条可以传到不受限制的用户目录
-
sudo scp /etc/kubernetes/admin.conf chenaws@k8snode2:~ -
当然后续也要把这个文件移到work的
/etc/kubernetes/下 -
sudo mv ~/admin.conf /etc/kubernetes/
出现这个直接yes
-
然后继续配置环境变量即可
-
成功！
为什么需要拷贝 admin.conf？
- 默认情况下，work节点使用
kubectl会查找~/.kube/config文件作为配置文件。 - 我们可以通过比较一开始的 master 节点和 worker 节点的
~/.kube/config文件配置来找到答案：
- 可以看到，worker节点根本就没有指明配置，所以使用不了 kubectl，那么我们的解决方案就是把master的配置直接复制到work上去
为什么需要配置环境变量？
- 如果你将
admin.conf拷贝到了/etc/kubernetes目录下，需要通过设置环境变量KUBECONFIG来告诉kubectl使用这个新的配置文件路径。 - 配置环境变量后，
kubectl就可以正确加载admin.conf文件，从而访问 Kubernetes 集群。
为什么不用 cp？
cp是本地拷贝命令，只能在同一台主机上使用。scp是跨主机拷贝命令，用于在不同主机之间传输文件。因为admin.conf文件在 master 节点上，而你需要将它拷贝到工作节点上，所以必须使用scp。
命令解析
bash
scp /etc/kubernetes/admin.conf root@k8snode2:/etc/kubernetesscp：这是一个安全拷贝命令，用于在不同主机之间拷贝文件。它基于 SSH 协议，因此传输过程是加密的。/etc/kubernetes/admin.conf：这是 Kubernetes 集群的管理员配置文件，包含了访问集群所需的认证信息（如证书、令牌等）。root@k8snode2：目标主机的用户名和主机名。这里假设目标主机的用户名是root，主机名是k8snode2。/etc/kubernetes：目标路径，将文件拷贝到目标主机的/etc/kubernetes目录下。
命令解析
bash
echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile
source ~/.bash_profileecho：用于输出字符串。export KUBECONFIG=/etc/kubernetes/admin.conf：设置环境变量KUBECONFIG，指定kubectl使用的配置文件路径。>> ~/.bash_profile：将输出追加到~/.bash_profile文件中。~/.bash_profile是用户登录时加载的配置文件之一，用于设置环境变量。source ~/.bash_profile：重新加载~/.bash_profile文件，使刚刚设置的环境变量生效。
总结
-
拷贝
admin.conf：- 使用
scp将admin.conf从 master 节点拷贝到工作节点的/etc/kubernetes目录。 - 这样可以让工作节点上的
kubectl使用这个配置文件访问集群。
- 使用
-
配置环境变量：
- 设置
KUBECONFIG环境变量，指定kubectl使用的配置文件路径。 - 通过
source ~/.bash_profile使环境变量生效。
- 设置