根據預設,您無法控制 Pod 執行的叢集節點,因此 Pod 沒有穩定的 IP 位址。如要取得在 Kubernetes 中執行的應用程式 IP 位址,您必須在 Pod 上方定義稱為 Kubernetes 服務的網路抽象層。Kubernetes Service 會為一組 Pod 提供穩定的網路端點。Service 類型有許多種,包括 LoadBalancer Service,這類 Service 會公開外部 IP 位址,方便您從叢集外部連線至應用程式。
Kubernetes 也有內建的 DNS 系統,可解析內部地址,並將 DNS 名稱 (例如 helloserver.default.cluster.local) 指派給服務。這樣一來,叢集內的 Pod 就能使用穩定位址存取叢集中的其他 Pod。您無法在叢集外部使用這個 DNS 名稱,例如從 Cloud Shell。
Kubernetes「控制層」是一組系統元件,可管理叢集的整體狀態,包括「Kubernetes API 伺服器」,讓您使用 kubectl 和其他工具與叢集和應用程式互動;「排程器」,可在可用節點上排定 Pod;以及「控制器」,可追蹤及管理叢集狀態。在 GKE 中,控制層是由 Google Cloud提供及管理。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-01 (世界標準時間)。"],[],[],null,["# Start learning about Kubernetes\n\n*** ** * ** ***\n\nGKE is based on the open source container orchestration platform\nKubernetes, and a lot of the documentation on this site assumes that you're\nalready familiar with basic Kubernetes concepts and terminology. If you're not,\nthis page provides a quick overview of Kubernetes fundamentals, with links to\nrecommended reading to get you started.\n\nKey concepts\n------------\n\nThe following are some key concepts that we use throughout the\nGKE documentation. This is not an exhaustive list of Kubernetes\nconcepts; you can find much more to read and explore in the provided topics from\nthe Kubernetes documentation and our [recommended\nreading](#recommended_reading).\n\n### Nodes and clusters\n\nAll Kubernetes workloads run on *nodes* . In GKE, a node is a\nCompute Engine virtual machine (VM). On other Kubernetes platforms, a node could be\neither a physical or virtual machine. Each node is managed by the Kubernetes\ncontrol plane and has all the necessary components to run Pods. A *cluster* is a\nset of nodes that can be treated together as a single entity, on which you\ndeploy a containerized application.\n\nLearn more in the Kubernetes documentation:\n\n- [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/)\n- [Cluster architecture](https://kubernetes.io/docs/concepts/architecture/)\n- [Nodes](https://kubernetes.io/docs/concepts/architecture/nodes/)\n\n### Namespaces\n\nKubernetes namespaces provide a mechanism for further grouping and selecting\nresources such as Pods and Services within a cluster, for example if you have\nmultiple application teams running workloads on a single cluster.\n\nLearn more in the Kubernetes documentation:\n\n- [Namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)\n\n### Pods\n\nIn Kubernetes, containerized applications run inside a *Pod* . A Pod is the\nsmallest deployable unit of computing that you can create and manage in\nKubernetes. A Pod has one or more *containers* . When a Pod runs multiple\ncontainers (for example, an application server and a [proxy\nserver](https://wikipedia.org/wiki/Proxy_server)), the containers are managed as\na single entity and share the Pod's resources.\n\nLearn more in the Kubernetes documentation:\n\n- [Pods](https://kubernetes.io/docs/concepts/workloads/pods/)\n- [Containers](https://kubernetes.io/docs/concepts/containers/)\n\n### Controllers\n\nKubernetes controllers track and manage the state of your clusters and\nworkloads, based on the desired state that you specify (for example, \"I would\nlike to run three of this Pod on this cluster, with this container in each\nPod\"). Different controllers track different Kubernetes resource types,\nincluding the following:\n\n- **Deployments** : A *Deployment* is a Kubernetes object that represents one or more identical Pods, called *replicas*. A Deployment runs multiple replicas of the Pods distributed among the nodes of a cluster. A Deployment automatically replaces any Pods that fail or become unresponsive.\n- **StatefulSet** : A *StatefulSet* is like a Deployment but maintains a persistent unique identity for each of its Pods. StatefulSets can be useful in applications with persistent state (stateful applications).\n- **DaemonSets** : A Kubernetes *DaemonSet* lets you add default Pods to some or all of your nodes. These are often \"helper\" services for your workloads, such as a log-collection daemon or a monitoring daemon.\n- **ReplicaSets** : A *ReplicaSet* is a set of identical Pods. A ReplicaSet is usually managed as part of a Deployment.\n\nLearn more in the Kubernetes documentation:\n\n- [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\n- [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)\n- [DaemonSets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)\n- [ReplicaSets](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/)\n\n### Kubernetes Service\n\nBy default, you can't control which cluster node a Pod is running on, so Pods\ndon't have stable IP addresses. To get an IP address for an application running\nin Kubernetes, you must define a networking abstraction on top of its Pods\ncalled a [Kubernetes\nService](/kubernetes-engine/docs/concepts/network-overview#services). A\nKubernetes Service provides a stable networking endpoint for a set of Pods.\nThere are several [types of\nService](/kubernetes-engine/docs/concepts/service#types_of_services), including\n`LoadBalancer` Services that expose an external IP address so that you can\nreach applications from outside their cluster.\n\nKubernetes also has a built-in DNS system for internal address resolution, which\nassigns DNS names (for example, `helloserver.default.cluster.local`) to\nServices. This allows Pods inside the cluster to reach other Pods in the\ncluster using a stable address. You can't use this DNS name outside the cluster,\nsuch as from Cloud Shell.\n\nLearn more in the Kubernetes documentation:\n\n- [Services](https://kubernetes.io/docs/concepts/services-networking/service/)\n\n### Storage\n\nIf your applications need to save data that exists beyond the lifetime of their\nPod (stateful applications), you can use a Kubernetes *PersistentVolume* object\nto provision this storage. In GKE, PersistentVolume storage is\nbacked by Compute Engine disks. You can also choose to use\nephemeral storage, which is destroyed when the corresponding Pod terminates.\n\nLearn more in the Kubernetes documentation:\n\n- [Volumes](https://kubernetes.io/docs/concepts/storage/volumes/)\n- [PersistentVolumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)\n\n### Kubernetes control plane\n\nThe Kubernetes *control plane* is a set of system components that manage the\noverall state of your cluster, including the *Kubernetes API server* that lets\nyou interact with your clusters and applications by using `kubectl` and other\ntools, a *scheduler* to schedule Pods on available nodes, and the *controllers*\nthat track and manage cluster state. In GKE, the control plane is\nprovided and managed by Google Cloud.\n\nLearn more in the Kubernetes documentation:\n\n- [Control plane components](https://kubernetes.io/docs/concepts/architecture/#control-plane-components)\n\n### Role-based access control (RBAC)\n\nKubernetes includes a *role-based access control (RBAC)* mechanism that lets you\ncreate authorization policies for accessing your clusters and their resources.\nWhen using GKE, you'll often use a combination of Kubernetes RBAC\nand Google Cloud's Identity and Access Management to secure your applications.\n\nLearn more in the Kubernetes documentation:\n\n- [Role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)\n\nRecommended reading\n-------------------\n\nThis section provides links to recommended resources for learning more about\nKubernetes. In particular, [Kubernetes.io](https://kubernetes.io), the official\nKubernetes website, has lots of up-to-date, reliable material about all\nthings Kubernetes.\n\n### Guides and tutorials\n\n- [Kubernetes overview](https://kubernetes.io/docs/concepts/overview/): A thorough conceptual overview of Kubernetes. [Why you need Kubernetes and\n what it can\n do](https://kubernetes.io/docs/concepts/overview/#why-you-need-kubernetes-and-what-can-it-do) is a great introduction to the problems that Kubernetes can solve.\n- [Tutorial: Learn Kubernetes\n basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/): Walks you through the basics of Kubernetes with a simple example.\n- [Tutorial: Introducing containers](/kubernetes-engine/docs/learn/containers): Learn about containers and container orchestration with a simple example application, finishing with the example running on GKE.\n- [Kubernetes tutorials](https://kubernetes.io/docs/tutorials/): When you're ready to move beyond the basics, this section of the Kubernetes documentation provides tutorials on a variety of Kubernetes topics, from stateful applications to security.\n\n### Reference documentation\n\n- [Kubernetes\n glossary](https://kubernetes.io/docs/reference/glossary/?fundamental=true): A comprehensive, standardized list of Kubernetes terminology. If you're not sure about a Kubernetes term, here's where to look it up!\n\n### Videos\n\n- [Learn Kubernetes with\n Google](https://www.youtube.com/playlist?list=PLxNYxgaZ8Rscf-XJ5VfXgbDAk1vL4xaMl): A playlist of video guides from Google that cover different Kubernetes features and functionalities, with material for both developers and operators.\n\n### Comic\n\n- [Kubernetes comic](/kubernetes-engine/kubernetes-comic): Discover the history of Kubernetes and how to use it for continuous integration and delivery, with the unlikely help of the Goddess of Wisdom (and containerized applications)."]]