#gkeclusters

DNS-Based Endpoints

In order to prevent unwanted access while maintaining cluster management, it is crucial to restrict access to the cluster control plane, which processes Kubernetes API calls, as you are aware if you use Google Kubernetes Engine (GKE).

Authorized networks and turning off public endpoints were the two main ways that GKE used to secure the control plane. However, accessing the cluster may be challenging when employing these techniques. To obtain access through the cluster’s private network, you need to come up with innovative solutions like bastion hosts, and the list of permitted networks needs to be updated for every cluster.

Google Cloud is presenting a new DNS-based endpoint for GKE clusters today, which offers more security restrictions and access method flexibility. All clusters have the DNS-based endpoint available today, irrespective of cluster configuration or version. Several of the present issues with Kubernetes control plane access are resolved with the new DNS-based endpoint, including:

Complex allowlist and firewall setups based on IP: ACLs and approved network configurations based on IP addresses are vulnerable to human setup error.

IP-based static configurations: You must adjust the approved network IP firewall configuration in accordance with changes in network configuration and IP ranges.

Proxy/bastion hosts: You must set up a proxy or bastion host if you are accessing the GKE control plane from a different cloud location, a distant network, or a VPC that is not the same as the VPC where the cluster is located.

Due to these difficulties, GKE clients now have to deal with a complicated configuration and a perplexing user experience.

Introducing a new DNS-based endpoint

Any network that can connect to Google Cloud APIs, such as VPC networks, on-premises networks, or other cloud networks, can access the frontend that the DNS name resolves to. This front-end Each cluster control plane has its own DNS or fully qualified domain name (FQDN) with the new DNS-based endpoint for GKE routes traffic to your cluster after using security policies to block unwanted traffic.Image credit to Google cloud

This strategy has several advantages:

Simple flexible access from anywhere

Proxy nodes and bastion hosts are not required when using the DNS-based endpoint. Without using proxies, authorized users can access your control plane from various clouds, on-premises deployments, or from their homes. Transiting various VPCs is unrestricted with DNS-based endpoints because all that is needed is access to Google APIs. You can still use VPC Service Controls to restrict access to particular networks if you’d like.

Dynamic Security

The same IAM controls that safeguard all GCP API access are also utilized to protect access to your control plane over the DNS-based endpoint. You can make sure that only authorized users, regardless of the IP address or network they use, may access the control plane by implementing identity and access management (IAM) policies. You can easily remove access to a specific identity if necessary, without having to bother about network IP address bounds and configuration. IAM roles can be tailored to the requirements of your company.

See Customize your network isolation for additional information on the precise permissions needed to set up IAM roles, rules, and authentication tokens.

Two layers of security

You may set up network-based controls with VPC Service Controls in addition to IAM policies, giving your cluster control plane a multi-layer security architecture. Context-aware access controls based on network origin and other attributes are added by VPC Service Controls. The security of a private cluster that is only accessible from a VPC network can be equaled.

All Google Cloud APIs use VPC Service Controls, which ensures that your clusters’ security setup matches that of the services and data hosted by all other Google Cloud APIs. For all Google Cloud resources used in a project, you may provide solid assurances for the prevention of illegal access to data and services. Cloud Audit Logs and VPC Service Controls work together to track control plane access.

How to configure DNS-based access

The procedure of setting up DNS-based access for the GKE cluster control plane is simple Check the next steps.

Enable the DNS-based endpoint

Use the following command to enable DNS-based access for a new cluster:

$ gcloud container clusters create $cluster_name –enable-dns-access

As an alternative, use the following command to allow DNS-based access for an existing cluster:

$ gcloud container clusters update $cluster_name –enable-dns-acces

Configure IAM

Requests must be authenticated with a role that has the new IAM authorization in order to access the control plane.

roles/container.developer

roles/container.viewer

Ensure your client can access Google APIs

You must confirm that your client has access to Google APIs if it is connecting from a Google VPC. Activating Private Google Access, which enables clients to connect to Google APIs without using the public internet, is one approach to accomplish this. Each subnet has its own configuration for private Google Access.

Tip: Private Google Access is already enabled for node subnetworks.

[Selective] Setting up access to Google APIs via Private Service Connect

The Private Service Connect for Google APIs endpoint, which is used to access the other Google APIs, can be used to access the DNS endpoint of the cluster. To configure Private Service Connect for Google APIs endpoints, follow the instructions on the Access Google APIs through endpoints page.

Since using a custom endpoint to access the cluster’s DNS is not supported, as detailed in the use an endpoint section, in order to get it to work, you must create a CNAME to “gke.goog” and an A record between “gke.goog” and the private IP allocated to Private Service Connect for Google APIs.

Try DNS access

You can now try DNS-based access. The following command generates a kubeconfig file using the cluster’s DNS address:

gcloud container clusters get-credentials $cluster_name –dns-endpoint

Use kubectl to access your cluster. This allows Cloud Shell to access clusters without a public IP endpoint, previously required a proxy.

Extra security using VPC Service Controls

Additional control plane access security can be added with VPC Service Controls.

What about the IP-based endpoint?

You can test DNS-based control plane access without affecting your clients by using the IP-based endpoint. After you’re satisfied with DNS-based access, disable IP-based access for added security and easier cluster management:

gcloud container clusters update $cluster_name –enable-ip-access=false

Do you want to pay less for storing GKE blocks? Storage Pool for Hyperdisks may assist Whether you’re managing GKE clusters, conventional virtual machines, or both, it’s critical to automate as many of your operational chores as you can in an economical way.

Pool Storage

Hyperdisk Storage Pool are a pre-purchased collection of capacity, throughput, and IOPS that you can then supply to your applications as required. Hyperdisk is a next-generation network connected block storage solution. Hyperdisk block storage disks allow you to optimize operations and costs by sharing capacity and performance across all the disks in a pool when you put them in storage pools. Hyperdisk Storage Pools may reduce your Total Cost of Ownership (TCO) associated with storage by up to 30–50%, and as of Google Kubernetes Engine (GKE) 1.29.2, they can be used on GKE!

Thin provisioning in Storage Pool makes this feasible by enabling you to use the capacity that is allocated inside the pool only when data is written, not when pool disks are provided. Rather of provisioning each disk for peak demand regardless of whether it ever experiences that load, capacity, IOPS, and throughput are bought at the pool level and used by the disks in the pool on an as-needed basis, enabling you to share resources as needed:

Why is Hyperdisk used?

Hyperdisk, the next generation of Google Cloud persistent block storage, is different from conventional persistent disks in that it permits control of throughput and IOPS in addition to capacity. Additionally, even after the disks are first configured, you may adjust their performance to match your specific application requirements, eliminating extra capacity and enabling cost savings.Image Credit Google Cloud

How about Storage Pool?

In contrast, storage pools allow you to share a thinly-provisioned capacity pool across many Hyperdisks in a single project that are all located in the same zone, or “Advanced Capacity” Storage Pool. Rather to using storage capacity that is provided, you buy the capacity up front and just use it for data that is written. Throughput and IOPS may be adjusted in a similar manner in a storage pool referred to as “Advanced Capacity & Advanced Performance.”

Combining Hyperdisk with Storage Pools reduces the total cost of ownership (TCO) for block storage by shifting management responsibilities from the disk level to the pool level, where all disks within the pool absorb changes. A Storage Pool is a zonal resource with a minimum capacity of 10TB and requires a hyperdisk of the same kind (throughput or balanced).

Hyperdisk

Storage Pool + Hyperdisk on GKE

Hyperdisk Balanced boot disks and Hyperdisk Balanced or Hyperdisk Throughput attached disks may now be created on GKE nodes within Storage Pool, as of GKE 1.29.2.

Let’s imagine you want to be able to adjust the performance to suit your workload for a demanding stateful application that is executing in us-central-a. You decide to use Hyperdisk Balanced for the workload’s block storage. You employ a Hyperdisk Balanced Advanced Capacity, Advanced Performance Storage Pools in place of trying to right-size each disk in your application. The capacity and performance are paid for beforehand.

Pool performance is used up when the disks in the storage pool notice an increase in IOPS or throughput, while pool capacity is only used up when your application writes data to the disks. Prior to creating the Hyperdisks inside the Storage Pool(s) must be created.

Google Cloud Hyperdisk

Use the following gcloud command to establish an Advanced Capacity, Advanced Performance StoragePools:gcloud compute storage-pools create pool-us-central1-a --provisioned-capacity=10tb --storage-pool-type=hyperdisk-balanced --zone=us-central1-a --project=my-project-id --capacity-provisioning-type=advanced --performance-provisioning-type=advanced --provisioned-iops=10000 --provisioned-throughput=1024

The Pantheon UI may also be used to construct Storage Pools.

You may also provide your node boot disks in the storage pool if your GKE nodes are utilizing Hyperdisk Balanced as their boot drives. This may be set up at cluster or node-pool construction, as well as during node-pool updates. You may use the Pantheon UI or the following gcloud command to provide your Hyperdisk Balanced node boot drives in your Storage Pool upon cluster setup. Keep in mind that your Storage Pool has to be established in the same zone as your cluster and that the machine type of the nodes needs to support Hyperdisk Balanced.

You must use the storage-pools StorageClass argument to define your Storage Pool in order to deploy the Hyperdisk Balanced disks that your stateful application uses in it. The Hyperdisk Balanced volume that your application will utilize is then provisioned using a Persistent Volume Claim (PVC) that uses the StorageClass.

The provisioned-throughput-on-create and provisioned-iops-on-create parameters are optional and may be specified by the StorageClass. The volume will default to 3000 IOPS and 140Mi throughput if provisioned-throughput-on-create and provisioned-iops-on-create are left empty. Any IOPS or Throughput from the StoragePool will only be used by IOPS and Throughput values that exceed these preset levels.

Google Hyperdisk

The allowed IOPS and throughput figures vary based on the size of the drive.

Only 40 MiB of throughput and 1000 IOPS will be used by volumes allocated with this StorageClass from the Storage Pools.

Next, create a PVC with a reference to the StorageClass storage-pools-sc.

The pooling-storage-sc When a Pod utilizing the PVC is formed, Storage Class’s Volume Binding Mode: Wait For First Consumer is used, delaying the binding and provisioning of a Persistent Volume.

Finally, utilize the aforementioned PVC to include these Hyperdisk Volumes into your Stateful application. It is necessary to schedule your application to a node pool that has computers capable of attaching Hyperdisk Balanced.

NodeSelectors are used in the Postgres deployment to make sure that pods are scheduled to nodes that allow connecting Hyperdisk Balanced, or C3 machine types.

You ought now be able to see that your storage pools has your Hyperdisk Balanced volume deployed.

Next actions

For your stateful applications, you may optimize storage cost reductions and efficiency by using a Storage Pools + Hyperdisk approach for GKE.