Kubernetes入门：从运行应用到深入理解Pods

# Kubernetes 入门：从运行应用到深入理解 Pods ## 1. 在 Kubernetes 上运行首个应用 ### 1.1 检查应用运行的节点 在 Kubernetes 环境中，你可能会好奇 Pod 被调度到了哪些节点上。不过，在 Kubernetes 的世界里，只要 Pod 被调度到能提供其正常运行所需 CPU 和内存的节点，具体是哪个节点并不那么重要。 无论 Pod 被调度到哪个节点，容器内运行的所有应用都具有相同类型的操作系统环境。每个 Pod 都有自己的 IP 地址，并且可以与其他任何 Pod 进行通信，无论这些 Pod 是否运行在同一节点上。每个 Pod 都会获得所需的计算资源，因此这些资源由哪个节点提供并无区别。 如果你想查看 Pod 被调度到的节点信息，可以使用以下方法： - **使用 -o wide 选项列出 Pod 时显示 Pod IP 和节点信息**： `kubectl get pods -o wide` 命令通常不会显示 Pod 被调度到的节点信息，但使用 `-o wide` 选项可以额外显示 Pod 的 IP 地址和运行该 Pod 的节点。示例如下： ```plaintext $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE kubia-hczji 1/1 Running 0 7s 10.1.0.2 gke-kubia-85... ``` - **使用 kubectl describe 命令检查 Pod 的其他详细信息**： `kubectl describe` 命令可以显示 Pod 的许多其他详细信息，包括 Pod 被调度到的节点、启动时间、运行的镜像等。示例如下： ```plaintext $ kubectl describe pod kubia-hczji Name: kubia-hczji Namespace: default Node: gke-kubia-85f6-node-vs9f/10.132.0.3 Start Time: Fri, 29 Apr 2016 14:12:33 +0200 Labels: run=kubia Status: Running IP: 10.1.0.2 Controllers: ReplicationController/kubia Containers: ... Conditions: Type Status Ready True Volumes: ... Events: ... ``` ### 1.2 介绍 Kubernetes 仪表盘 除了使用 `kubectl` 命令行工具，Kubernetes 还提供了一个可视化的 Web 仪表盘，方便你以图形化界面查看集群中部署的所有 Pod、ReplicationControllers、Services 等对象，并且可以进行创建、修改和删除操作。 #### 1.2.1 在 Google Kubernetes Engine（GKE）中访问仪表盘 如果你使用的是 Google Kubernetes Engine，可以通过 `kubectl cluster-info` 命令找到仪表盘的 URL： ```plaintext $ kubectl cluster-info | grep dashboard kubernetes-dashboard is running at https://104.155.108.191/api/v1/proxy/ ➥ namespaces/kube-system/services/kubernetes-dashboard ``` 打开该 URL 后，会提示输入用户名和密码。你可以通过以下命令找到用户名和密码： ```plaintext $ gcloud container clusters describe kubia | grep -E "(username|password):" password: 32nENgreEJ632A12 username: admin ``` #### 1.2.2 使用 Minikube 时访问仪表盘 如果你使用 Minikube 运行 Kubernetes 集群，可以使用以下命令在默认浏览器中打开仪表盘： ```plaintext $ minikube dashboard ``` 与 GKE 不同，使用 Minikube 时无需输入任何凭据即可访问仪表盘。 ### 1.3 总结 通过以上操作，你现在应该掌握了以下技能： 1. 拉取并运行任何公开可用的容器镜像。 2. 将应用打包成容器镜像，并通过推送到远程镜像仓库使其可供他人使用。 3. 进入正在运行的容器并检查其环境。 4. 在 Google Kubernetes Engine 上设置多节点 Kubernetes 集群。 5. 为 `kubectl` 命令行工具配置别名和制表符自动补全。 6. 列出并检查 Kubernetes 集群中的 Nodes、Pods、Services 和 ReplicationControllers。 7. 在 Kubernetes 中运行容器并使其可从集群外部访问。 8. 对 Pods、ReplicationControllers 和 Services 之间的关系有基本的了解。 9. 通过更改 ReplicationController 的副本数量来水平扩展应用。 10. 在 Minikube 和 GKE 上访问基于 Web 的 Kubernetes 仪表盘。 ## 2. 深入理解 Kubernetes 中的 Pods ### 2.1 介绍 Pods Pod 是 Kubernetes 中的基本构建块，它是一组共置的容器。在 Kubernetes 中，你总是以 Pod 为单位来部署和操作容器，而不是单独部署容器。虽然 Pod 通常只包含一个容器，但也可以包含多个容器。关键在于，当 Pod 包含多个容器时，这些容器总是运行在同一个工作节点上，不会跨多个节点。 ### 2.2 理解为何需要 Pods #### 2.2.1 为何多个容器优于单个容器运行多个进程 假设一个应用由多个进程组成，这些进程通过进程间通信（IPC）或本地存储文件进行通信，这就要求它们运行在同一台机器上。在 Kubernetes 中，进程通常运行在容器中，每个容器就像一台独立的机器。你可能会认为在单个容器中运行多个进程是合理的，但实际上并非如此。 容器的设计初衷是每个容器只运行一个进程（除非该进程本身会派生子进程）。如果在单个容器中运行多个不相关的进程，你需要负责确保所有这些进程持续运行、管理它们的日志等。例如，你需要包含一个机制来在进程崩溃时自动重启它们。此外，所有这些进程都会将日志输出到同一个标准输出，这会让你很难分辨是哪个进程产生的日志。 因此，你应该为每个进程运行一个单独的容器，这也是 Docker 和 Kubernetes 的推荐使用方式。 #### 2.2.2 理解 Pods 由于不建议将多个进程组合到单个容器中，因此需要一个更高级的构造来将容器绑定在一起并作为一个单元进行管理，这就是 Pod 的设计初衷。 Pod 允许你将密切相关的进程一起运行，并为它们提供几乎相同的环境，就好像它们都运行在单个容器中一样，同时又保持一定的隔离性。这样，你既可以利用容器提供的所有特性，又能让进程感觉像是在一起运行。 #### 2.2.3 理解同一 Pod 内容器之间的部分隔离性 在之前的学习中，你知道容器之间是完全隔离的，但现在你要隔离的是容器组而不是单个容器。你希望每个组内的容器共享某些资源，但不是全部，这样它们就不会完全隔离。Kubernetes 通过配置 Docker 让 Pod 内的所有容器共享同一组 Linux 命名空间，而不是每个容器都有自己的命名空间来实现这一点。 由于 Pod 内的所有容器都在相同的网络和 UTS 命名空间（这里指的是 Linux 命名空间）下运行，它们共享相同的主机名和网络接口。同样，Pod 内的所有容器都在相同的 IPC 命名空间下运行，可以通过 IPC 进行通信。在最新的 Kubernetes 和 Docker 版本中，它们还可以共享相同的 PID 命名空间，但该功能默认未启用。 需要注意的是，当同一 Pod 内的容器使用单独的 PID 命名空间时，在容