男头发稀少适合什么发型

Kubernetes is an open-source system for managing containerized applications in a clustered environment. Its focus is to improve how you manage related, distributed components and services across varied infrastructure.

DigitalOcean Kubernetes is a managed Kubernetes service lets you deploy scalable and secure Kubernetes clusters without the complexities of administrating the control plane. We manage the Kubernetes control plane and the underlying containerized infrastructure.

The Managed Elements of DigitalOcean Kubernetes

DigitalOcean Kubernetes provides administrator access to the cluster and full access to the Kubernetes API with no restrictions on which API objects you can create. We manage key services and settings on your behalf that you cannot or should not modify.

You retain full access to the cluster with existing toolchains. You have cluster-level administrative rights to create and delete any Kubernetes API objects through the DigitalOcean API and doctl.

There are no restrictions on the API objects you can create as long as the underlying Kubernetes version supports them. We offer the latest version of Kubernetes as well as earlier patch levels of the latest minor version for special use cases. You can also install popular tools like Helm, metrics-server, and Istio.

We only support features that are in a beta and general availability stage in upstream Kubernetes. See the Kubernetes documentation to check which feature is in the alpha, beta or general availability stage.

For updates on DOKS’s latest features and integrations, see the DOKS release notes. For a full list of changes for each available version of Kubernetes, including updates to the backend, API, and system components, see the DOKS changelog.

Conformance Certification

DOKS conforms to the Cloud Native Computing Foundation’s Kubernetes Software Conformance Certification program and is proud to be a CNCF Certified Kubernetes product.

In addition, we run our own extended suite of end-to-end tests on every DOKS release to ensure stability, performance, and upgrade compatibility.

Worker Nodes and Node Pools

Worker nodes are built on Droplets and can be shared or dedicated CPUs, and GPUs. Unlike standalone Droplets, you manage worker nodes with the Kubernetes command-line client kubectl and cannot access them with SSH. On both the control plane and the worker nodes, DigitalOcean maintains the system updates, security patches, operating system configuration and installed packages.

All the worker nodes within a node pool have identical resources, but each node pool can have a different worker configuration. This lets you have different services on different node pools, where each pool has the RAM, CPU, and attached storage resources the service requires.

You can create and modify node pools at any time. Worker nodes are automatically deleted and recreated when needed, and you can manually recycle worker nodes. Nodes in the node pool inherit the node pool’s naming scheme when you first create a node pool, however, renaming a node pool does not rename the nodes. Nodes inherit the new naming scheme only when they are recycled or the node pool is resized, creating new nodes.

Kubernetes role-based access control (RBAC) is enabled by default. See Using RBAC Authorization for details.

Scale Up to 1000 Nodes Per Cluster

For clusters with VPC-native networking, you can scale up to 1000 worker nodes using the DigitalOcean API or CLI. To do this, use a custom pod overlay subnet with a /15 network to support at least 1024 nodes. For more information, see Create a Cluster with VPC-native Networking.

Persistent Data

You can persist data in DigitalOcean Kubernetes clusters to volumes using the DigitalOcean CSI plugin. (See the feature overview page to learn which volume features are available on DigitalOcean Kubernetes.) We do not recommend using HostPath volumes because nodes are frequently replaced and all data stored on the nodes are lost.

You can also persist data to DigitalOcean object storage by using the Spaces API to interact with Spaces from within your application.

Load Balancing

The DigitalOcean Kubernetes Cloud Controller supports provisioning DigitalOcean Load Balancers.

VPC Networks

Clusters are added to a VPC network for the datacenter region by default. This keeps traffic between clusters and other applicable resources from being routed outside the datacenter over the public internet.

Cluster networking is preconfigured with Cilium. Overlay networking is preconfigured with Cilium and supports network policies.

VPC-Native Networking

VPC-native cluster networking allows you to route traffic directly between pods and other resources on VPC networks such as Droplets and managed databases. You can also expose Kubernetes services to the VPC network using internal load balancers.

We have enabled the Gateway API by default on clusters with VPC-native networking running on Kubernetes version 1.33 or higher. This feature is in public preview.

VPC-native networking is available on Kubernetes version 1.31 and later, using Cilium’s full kube-proxy replacement based on eBPF. Cluster-internal services function the same as traditional clusters, but are fully managed by eBPF instead of kube-proxy.

In traditional DOKS clusters, nodes are added to a VPC network, but pods and services operate on a separate virtual network. As a result, pods and services cannot communicate directly with resources in the VPC or peered VPCs and require a network translation step that can introduce inefficiencies or inconvenience.

When creating VPC-native clusters, you provide two additional subnet ranges that are used for pod and service networking. These subnet ranges must not overlap with each other or with any VPCs or VPC-native clusters on the team. With these subnets, VPC-native clusters enable transparent communication between the pod network and other peered VPC networks, including the node VPC, without requiring network translation.

You cannot convert existing clusters to use VPC-native because Kubernetes does not support changing the networking stack of a running cluster.

Tags

Clusters are automatically tagged with k8s and the specific cluster ID, like k8s:EXAMPLEc-3515-4a0c-91a3-2452eEXAMPLE. Worker nodes are additionally tagged with k8s:worker.

You can add custom tags to a cluster and its node pools. Any custom tags added to worker nodes in a node pool (for example, from the Droplets page), are deleted to maintain consistency between the node pool and its worker nodes.