Services Flashcards
Cloud Logging
other modules
Cloud Logging, which is a real-time log-management system with storage, search, analysis, and monitoring support. Cloud Logging automatically collects log data from Google Cloud resources
View and analyze your log data by using the Google Cloud console, either with the Logs Explorer or the Log Analytics pages
When you want to troubleshoot and analyze the performance of your services and applications, we recommend that you use the Logs Explorer
When you’re interested in performing aggregate operations on your logs, for example, to compute the average latency for HTTP requests issued to a specific URL over time, use the Log Analytics interface
You can configure Cloud Logging to notify you when certain kinds of events occur in your logs
You don’t have to configure the location where logs are stored
- Cloud Logging bucket
- BigQuery dataset
- Cloud Storage bucket
- Pub/Sub topic
- Google Cloud project
https://cloud.google.com/logging/docs/overview
Dedicated Interconnect
networking
Dedicated Interconnect provides direct physical connections between your on-premises network and Google’s network. Dedicated Interconnect enables you to transfer large amounts of data between networks
Your network must physically meet Google’s network in a colocation facility. You must provide your own routing equipment
When you create a VLAN attachment, you associate it with a Cloud Router. This Cloud Router creates a BGP session for the VLAN attachment and its corresponding on-premises peer router. The Cloud Router receives the routes that your on-premises router advertises. These routes are added as custom dynamic routes in your VPC network. The Cloud Router also advertises routes for Google Cloud resources to the on-premises peer router.
10-Gbps circuits, single mode fiber, 10GBASE-LR (1310 nm), or 100-Gbps circuits, single mode fiber, 100GBASE-LR4
https://cloud.google.com/network-connectivity/docs/interconnect/concepts/dedicated-overview
Cloud Data Loss Prevention
other module
discover, classify, and protect your most sensitive data.
Sensitive Data Protection includes data discovery, inspection, de-identification, data risk analysis, and the DLP API.
Automated sensitive data discovery and classification
Sensitive data intelligence for security assessments
De-identification, masking, tokenization, and bucketing
Powerful and flexible masking of your AI/ML workloads
https://cloud.google.com/security/products/dlp?hl=en
Cloud Shell
other modules
Cloud Shell provisions a Compute Engine virtual machine running a Debian-based Linux operating system for your temporary use. This virtual machine is owned and managed by Google Cloud, so will not appear within any of your Google Cloud projects.
Cloud Shell instances are provisioned on a per-user, per-session basis. The instance persists while your Cloud Shell session is active; after an hour of inactivity, your session terminates and its VM is discarded
Persistent disk storage :
Cloud Shell provisions 5 GB of free persistent disk storage mounted as your $HOME directory on the virtual machine instance. This storage is on a per-user basis and is available across projects. Unlike the instance itself, this storage does not time out on inactivity. All files you store in your home directory, including installed software, scripts and user configuration files like .bashrc and .vimrc, persist between sessions. Your $HOME directory is private to you and can’t be accessed by other users.
Root user :
When you set up a Cloud Shell session, you get a regular Unix user account with a username based on your email address. With this access, you have full root privileges on your allocated VM and can even run sudo commands, if you need to.
https://cloud.google.com/shell/docs/how-cloud-shell-works
Cloud VPN
Networking
Cloud VPN securely extends your peer network to your Virtual Private Cloud (VPC) network through an IPsec VPN connection. The VPN connection encrypts traffic traveling between the networks, with one VPN gateway handling encryption and the other handling decryption. This process protects your data during transmission. You can also connect two VPC networks together by connecting two Cloud VPN instances. You cannot use Cloud VPN to route traffic to the public internet; it is designed for secure communication between private networks.
1 Gbps and 3 Gbps of bandwidth.
Google Cloud offers two types of Cloud VPN gateways:
HA VPN is a high-availability (HA) Cloud VPN solution that lets you securely connect your on-premises network to your VPC network through an IPsec VPN connection. Based on the topology and configuration, HA VPN can provide an SLA of 99.99% or 99.9% service availability.
Classic VPN gateways have a single interface, a single external IP address, and support tunnels that use static routing (policy based or route based) Classic VPN gateways provide an SLA of 99.9% service availability.
https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview
Sustained use discounts
Compute Engine offers sustained use discounts (SUDs) on resources that are used for more than 25% of a billing month and are not receiving any other discounts. Whenever you use an applicable resource for more than a fourth of a billing month, you automatically receive a discount for every incremental hour that you continue to use that resource. The discount increases incrementally with usage and you can get up to a 30% net discount off of the resource cost for virtual machine (VM) instances that run the entire month.
Limitations
Sustained use discounts have the following limitations:
Only Self-serve (or Online) Cloud Billing accounts are eligible for receiving SUDs. SUDs don't apply to the resource usage that is already covered by committed use discounts (CUDs). SUDs don't apply to VMs created using the App Engine (standard and flexible) environments and Dataflow. Only VMs created by Google Kubernetes Engine and Compute Engine are eligible for SUDs. Sustained use discounts apply only to the machine series listed in the Eligible resources and discount percentages section.
Eligible resources and discount percentages
The following resources are eligible to receive sustained use discounts:
The vCPUs and memory for general-purpose N1, N2, and N2D custom and predefined machine types The vCPUs and memory for compute-optimized C2 machine types The vCPUs and memory for memory-optimized M1 and M2 machine types The vCPUs and memory for sole-tenant nodes The premium cost for sole-tenant nodes, even if the vCPUs and memory in those nodes are covered by CUDs All GPU devices with the exception of NVIDIA H100, A100, and L4 GPU types.
https://cloud.google.com/compute/docs/sustained-use-discounts
Resource-based committed use discounts
other modules
Compute Engine provides resource-based committed use discounts (CUDs) for your predictable workloads to help you cut costs on resources that you need. You can purchase and renew resource-based committed use contracts or commitments in return for heavily discounted prices for VM usage.
Resource-based commitments are ideal for predictable and steady state usage. These commitments require no upfront costs. Compute Engine lets you purchase the following categories of resource-based commitments:
Hardware commitments: You can purchase hardware commitments for a specific machine series and commit to resources available for that machine series, such as vCPUs, memory, GPUs, Local SSD disks, and sole tenant nodes. For more information, see Purchase commitments without attached reservations and Purchase commitments with attached reservations. Software license commitments: You can purchase license commitments for applicable premium operating system (OS) licenses. For more information, see Purchase commitments for licenses.
https://cloud.google.com/compute/docs/instances/signing-up-committed-use-discounts
PCI DSS
The PCI Security Standards Council is a global forum for the ongoing development, enhancement, storage, dissemination, and implementation of security standards for account data protection. The Standards Council was established by the major credit card associations (Visa, MasterCard, American Express, Discover, JCB) as a separate organization to define appropriate practices that merchants and service providers should follow to protect cardholder data. It is this council of companies that created the Payment Card Industry (PCI) Data Security Standards (DSS).
https://cloud.google.com/security/compliance/pci-dss?hl=en
https://cloud.google.com/architecture/pci-dss-and-gke-guide?hl=en
https://cloud.google.com/architecture/limiting-compliance-scope-pci-environments-google-cloud
https://cloud.google.com/architecture/gke-pci-dss-blueprint
SLIs, SLOs, SLAs
It’s very important that you understand the level of service that you offer
your users. It’s almost impossible to manage a service well if you don’t
know what is important for that service and how to measure its behavior. To
that end, it’s important that you understand service level indicators (SLIs),
service level objectives (SLOs), and service level agreements (SLAs). You
may not see a question on the exam that asks you to define SLIs and SLOs,
but you may be presented with a data point or a requirement indicating that
the business is looking to maintain or achieve a higher SLA with a new
architecture. SLA seems to be a broad term that the industry uses to
represent a variety of meanings, so let’s break down these three terms here.
A service level indicator is a quantitative measure of a chosen
characteristic of the level of service that is provided from a product or
service. If the characteristic is availability, the SLI could be a percentage of
time, often expressed in the number of “nines” (for example, 99.99 percent
is “four nines”). Remember that SLA does not mean service level
availability—it means service level agreement, even though the availability
is oftentimes expressed in the agreement. The actual number itself, or the
range of numbers, is the service level objective. If we’re expecting 99.999
percent availability for a system, “five nines” is our objective and the
availability is our measure. What’s left if we don’t meet these requirements
is described in our service level agreement. The SLA is a contract that
describes the expectations and consequences of meeting or missing an SLO.
For example, if Google Cloud Storage doesn’t meet its availability targets
of 99.95 percent (for the storage class—there are other SLOs for other
storage classes), customers are eligible to receive financial credits of a
percentage of the monthly bill for the service.
In short, the SLI is the indicator, the measure itself—availability, error
rate, and so on. The SLO is the objective, the numerical value that describes
the expectation of the measure—99.99 percent availability, 2 to 5 percent
error rate, and so on. And the SLA is the agreement, the contracted
expectations of using the product or service and what happens if the
objectives aren’t met. Remember how important reliability is to a successful
product and business, and think about how you can use these acronyms
effectively in your business meetings.
Resumable uploads
This page discusses resumable uploads in Cloud Storage. Resumable uploads are the recommended method for uploading large files, because you don’t have to restart them from the beginning if there is a network failure while the upload is underway.
A resumable upload lets you resume data transfer operations to Cloud Storage after a communication failure has interrupted the flow of data. Resumable uploads work by sending multiple requests, each of which contains a portion of the object you’re uploading. This is different from a single-request upload, which contains all of the object’s data in a single request and must restart from the beginning if it fails part way through.
Use a resumable upload if you are uploading large files or uploading over a slow connection. For example file size cutoffs for using resumable uploads, see upload size considerations.
A resumable upload must be completed within a week of being initiated, but can be cancelled at any time.
Only a completed resumable upload appears in your bucket and, if applicable, replaces an existing object with the same name.
The creation time for the object is based on when the upload completes.
Object metadata set by the user is specified in the initial request. This metadata is applied to the object once the upload completes.
The JSON API also supports setting custom metadata in the final request if you include headers prefixed with X-Goog-Meta- in that request.
A completed resumable upload is considered one Class A operation.
https://cloud.google.com/storage/docs/resumable-uploads
Signed URLs
A signed URL is a URL that provides limited permission and time to make a request. Signed URLs contain authentication information in their query string, allowing users without credentials to perform specific actions on a resource.
In some scenarios, you might not want to require your users to have a Google account in order to access Cloud Storage, but you still want to control access using your application-specific logic. The typical way to address this use case is to provide a signed URL to a user, which gives the user read, write, or delete access to that resource for a limited time. You specify an expiration time when you create the signed URL. Anyone who knows the URL can access the resource until the expiration time for the URL is reached or the key used to sign the URL is rotated.
The most common uses for signed URLs are uploads and downloads, because in such requests, object data moves between requesters and Cloud Storage. In most other cases, such as copying objects, composing objects, deleting objects, or editing metadata, creating a signed URL and giving it to someone to use is an unnecessary extra step. Instead, you should consider a design in which the entity responsible for creating the signed URL directly makes the desired request to Cloud Storage.
https://cloud.google.com/storage/docs/access-control/signed-urls
Identity-Aware Proxy
IAP lets you establish a central authorization layer for applications accessed by HTTPS, so you can use an application-level access control model instead of relying on network-level firewalls.
IAP policies scale across your organization. You can define access policies centrally and apply them to all of your applications and resources. When you assign a dedicated team to create and enforce policies, you protect your project from incorrect policy definition or implementation in any application.
How IAP works
When an application or resource is protected by IAP, it can only be accessed through the proxy by principals, also known as users, who have the correct Identity and Access Management (IAM) role. When you grant a user access to an application or resource by IAP, they’re subject to the fine-grained access controls implemented by the product in use without requiring a VPN. When a user tries to access an IAP-secured resource, IAP performs authentication and authorization checks.
https://cloud.google.com/iap/docs/concepts-overview
GKE cluster architecture
A Kubernetes cluster consists of a control plane plus a set of worker machines, called nodes, that run containerized applications. Every cluster needs at least one worker node in order to run Pods.
The worker node(s) host the Pods that are the components of the application workload. The control plane manages the worker nodes and the Pods in the cluster. In production environments, the control plane usually runs across multiple computers and a cluster usually runs multiple nodes, providing fault-tolerance and high availability.
The control plane manages what runs on all of the cluster’s nodes. The control plane schedules workloads and manages the workloads’ lifecycle, scaling, and upgrades. The control plane also manages network and storage resources for those workloads. The control plane and nodes communicate with each other using Kubernetes APIs.
https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-architecture
https://kubernetes.io/docs/concepts/architecture/
VPN topologies
Sample Classic VPN topology
The following diagram shows a sample VPN connection between a Classic VPN gateway and your peer VPN gateway.
Redundancy and failover options
Option 1: Move to HA VPN
If your peer VPN gateway supports BGP, the recommended option is to move to a highly available (HA) Cloud VPN gateway.
Option 2: Use a second peer VPN gateway
For Classic VPN, if your on-premises side is hardware based, having a second peer VPN gateway provides redundancy and failover on that side of the connection. A second physical gateway lets you take one of the gateways offline for software upgrades or other scheduled maintenance. It also protects you in case of an outright failure in one of the devices.
Increased throughput and load balancing options
There are three options for scaling a Cloud VPN configuration:
Option 1: Scale the on-premises VPN gateway.
Option 2: Scale the Cloud VPN gateway. If your on-premises VPN gateway’s throughput capabilities are higher, and you want to scale higher throughput from the Cloud VPN gateway, you can set up a second Cloud VPN gateway.
Option 3: Scale both the on-premises VPN gateway and the Cloud VPN gateway.
https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview
https://cloud.google.com/network-connectivity/docs/vpn/concepts/classic-topologies
Bigquery Manage tables
Update table properties:
Expiration time
Description
Schema definition
Labels
Default rounding mode
Rename (copy) a table
Copy a table
Delete a table
Restore a deleted table
https://cloud.google.com/bigquery/docs/managing-tables#updating_a_tables_expiration_time
Bigquery partition expiration
Set the partition expiration
When you create a table partitioned by ingestion time or time-unit column, you can specify a partition expiration. This setting specifies how long BigQuery keeps the data in each partition. The setting applies to all partitions in the table, but is calculated independently for each partition based on the partition time.
A partition’s expiration time is calculated from the partition boundary in UTC. For example, with daily partitioning, the partition boundary is at midnight (00:00:00 UTC). If the table’s partition expiration is 6 hours, then each partition expires at 06:00:00 UTC the following day. When a partition expires, BigQuery deletes the data in that partition.
You can also specify a default partition expiration at the dataset level. If you set the partition expiration on a table, then the value overrides the default partition expiration. If you don’t specify any partition expiration (on the table or dataset), then partitions never expire.
https://cloud.google.com/bigquery/docs/partitioned-tables
https://cloud.google.com/bigquery/docs/managing-partitioned-tables#partition-expiration
Bigquery clustered tables
Clustered tables in BigQuery are tables that have a user-defined column sort order using clustered columns. Clustered tables can improve query performance and reduce query costs.
In BigQuery, a clustered column is a user-defined table property that sorts storage blocks based on the values in the clustered columns. The storage blocks are adaptively sized based on the size of the table. Colocation occurs at the level of the storage blocks, and not at the level of individual rows; for more information on colocation in this context, see Clustering.
A clustered table maintains the sort properties in the context of each operation that modifies it. Queries that filter or aggregate by the clustered columns only scan the relevant blocks based on the clustered columns, instead of the entire table or table partition. As a result, BigQuery might not be able to accurately estimate the bytes to be processed by the query or the query costs, but it attempts to reduce the total bytes at execution.
When you cluster a table using multiple columns, the column order determines which columns take precedence when BigQuery sorts and groups the data into storage blocks, as seen in the following example. Table 1 shows the logical storage block layout of an unclustered table. In comparison, table 2 is only clustered by the Country column, whereas table 3 is clustered by multiple columns, Country and Status.
https://cloud.google.com/bigquery/docs/clustered-tables
GKE cluster autoscaling
GKE’s cluster autoscaler automatically resizes the number of nodes in a given node pool, based on the demands of your workloads. When demand is low, the cluster autoscaler scales back down to a minimum size that you designate. This can increase the availability of your workloads when you need it, while controlling costs. You don’t need to manually add or remove nodes or over-provision your node pools. Instead, you specify a minimum and maximum size for the node pool, and the rest is automatic.
If resources are deleted or moved when autoscaling your cluster, your workloads might experience transient disruption. For example, if your workload consists of a controller with a single replica, that replica’s Pod might be rescheduled onto a different node if its current node is deleted. Before enabling cluster autoscaler, design your workloads to tolerate potential disruption or ensure that critical Pods are not interrupted.
Cluster autoscaler works per node pool. When you configure a node pool with cluster autoscaler, you specify a minimum and maximum size for the node pool.
Why use horizontal Pod autoscaling
When you first deploy your workload to a Kubernetes cluster, you may not be sure about its resource requirements and how those requirements might change depending on usage patterns, external dependencies, or other factors. Horizontal Pod autoscaling helps to ensure that your workload functions consistently in different situations, and lets you control costs by only paying for extra capacity when you need it.
It’s not always easy to predict the indicators that show whether your workload is under-resourced or under-utilized. The Horizontal Pod Autoscaler can automatically scale the number of Pods in your workload based on one or more metrics of the following types:
Actual resource usage: when a given Pod's CPU or memory usage exceeds a threshold. This can be expressed as a raw value or as a percentage of the amount the Pod requests for that resource. Custom metrics: based on any metric reported by a Kubernetes object in a cluster, such as the rate of client requests per second or I/O writes per second. This can be useful if your application is prone to network bottlenecks, rather than CPU or memory. External metrics: based on a metric from an application or service external to your cluster. For example, your workload might need more CPU when ingesting a large number of requests from a pipeline such as Pub/Sub. You can create an external metric for the size of the queue, and configure the Horizontal Pod Autoscaler to automatically increase the number of Pods when the queue size reaches a given threshold, and to reduce the number of Pods when the queue size shrinks.
https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler
https://cloud.google.com/kubernetes-engine/docs/concepts/horizontalpodautoscaler
Bigquery roles
BigQuery Data Viewer
(roles/bigquery.dataViewer)
When applied to a table or view, this role provides permissions to:
Read data and metadata from the table or view.
This role cannot be applied to individual models or routines.
When applied to a dataset, this role provides permissions to list all of the resources in the dataset (such as tables, views, snapshots, models, and routines) and to read their data and metadata with applicable APIs and in queries.
When applied at the project or organization level, this role can also enumerate all datasets in the project. Additional roles, however, are necessary to allow the running of jobs.
Lowest-level resources where you can grant this role:
Table
View
BigQuery Job User
(roles/bigquery.jobUser)
Provides permissions to run jobs, including queries, within the project.
Lowest-level resources where you can grant this role:
Project
https://cloud.google.com/bigquery/docs/access-control
StatefulSet dans GKE
StatefulSets represent a set of Pods with unique, persistent identities, and stable hostnames that GKE maintains regardless of where they are scheduled. The state information and other resilient data for any given StatefulSet Pod is maintained in persistent volumes associated with each Pod in the StatefulSet. StatefulSet Pods can be restarted at any time.
StatefulSets are valuable for applications that require one or more of the following.
Stable, unique network identifiers. Stable, persistent storage. Ordered, graceful deployment and scaling. Ordered, automated rolling updates.
https://cloud.google.com/kubernetes-engine/docs/concepts/statefulset
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
Cloud CDN
Cloud CDN (Content Delivery Network) uses Google’s global edge network to serve content closer to users, which accelerates your websites and applications.
Cloud CDN works with the global external Application Load Balancer or the classic Application Load Balancer to deliver content to your users. The external Application Load Balancer provides the frontend IP addresses and ports that receive requests and the backends that respond to the requests.
In Cloud CDN, these backends are also called origin servers. Figure 1 illustrates how responses from origin servers that run on virtual machine (VM) instances flow through an external Application Load Balancer before being delivered by Cloud CDN. In this situation, the Google Front End (GFE) comprises Cloud CDN and the external Application Load Balancer.
Cache hit ratio
The cache hit ratio is the percentage of times that a requested object is served from the cache. If the cache hit ratio is 60%, it means that the requested object is served from the cache 60% of the time and must be retrieved from the origin 40% of the time.
For information about how cache keys can affect the cache hit ratio, see Using cache keys. For troubleshooting information, see Cache hit ratio is low.
Cache keys
Each cache entry in a Cloud CDN cache is identified by a cache key. When a request comes into the cache, the cache converts the URI of the request into a cache key, and then compares it with keys of cached entries. If it finds a match, the cache returns the object associated with that key.
For backend services, Cloud CDN defaults to using the complete request URI as the cache key. For example, https://example.com/images/cat.jpg is the complete URI for a particular request for the cat.jpg object. This string is used as the default cache key. Only requests with this exact string match. Requests for http://example.com/images/cat.jpg or https://example.com/images/cat.jpg?user=user1 don’t match.
For backend buckets, the default is for the cache key to consist of the URI without the protocol or host. By default, only query parameters that are known to Cloud Storage are included as part of the cache key (for example, “generation”).
Thus, for a given backend bucket, the following URIs resolve to the same cached object:
http://example.com/images/cat.jpg https://example.com/images/cat.jpg https://example.com/images/cat.jpg?user=user1 http://example.com/images/cat.jpg?user=user1 https://example.com/images/cat.jpg?user=user2 https://media.example.com/images/cat.jpg https://www.example.com/images/cat.jpg
You can change which parts of the URI are used in the cache key. While the filename and path must always be part of the key, you can include or omit any combination of protocol, host, or query string when customizing your cache key. Using cache keys describes how to customize your cache keys.
https://cloud.google.com/cdn/docs/overview
Google Cloud Observability
Observability is a holistic approach to gathering and analyzing telemetry data in order to understand the state of your environment. Telemetry data is metrics, logs, traces, and other data generated by your applications and the application infrastructure that provide information about application health and performance.
Metrics
Metrics are numeric data about health or performance that you measure at regular intervals over time, such as CPU utilization and request latency. Unexpected changes to a metric might indicate an issue to investigate. Over time, you can also analyze metric patterns to better understand usage patterns and anticipate resource needs.
Logs
A log is a generated record of system or application activity over time. Each log is a collection of time stamped log entries, and each log entry describes an event at a specific point in time. A log often contains rich, detailed information that helps you understand what happened with a specific part of your application. However, logs don't provide good information about how a change in one component of your application relates to activity in another component. Traces can help to bridge that gap. Traces Traces represent the path of a request across the parts of your distributed application. A metric or log entry in one application component that triggered an alert notification might be a symptom of a problem that originates in another component. Traces let you follow the flow of a request and examine latency data to help you to identify the root cause of an issue. Other data You can gain additional insights by analyzing metrics, logs, and traces in the context of other data. For example, a label for the severity of an alert or the customer ID associated with a request in logs provide context that can be useful for troubleshooting and debugging.
Monitoring, debugging, and troubleshooting distributed applications can be difficult because there are many systems and software components involved, often with a mix of open source and commercial software.
Observability tools help you to navigate this complexity by collecting meaningful data and providing features to explore, analyze, and correlate the data. An observable environment helps you to:
Proactively detect issues before they impact your users Troubleshoot both known and new issues Debug applications during development Plan for and understand the impacts of changes to your applications Explore data to discover new insights
In short, an observable environment helps you to maintain application reliability. An application is reliable when it meets your current objectives for availability and resilience to failures.
Install the Ops Agent during VM creation
This document describes how the Google Cloud console can automatically install the Ops Agent for you when you create a VM instance. During the installation process, the Compute Engine VM Manager creates an Ops Agent OS policy that installs the agent and reinstalls it when necessary. The VM Manager helps you get the Ops Agent running on your VM and ensures that the agent is always installed.
https://cloud.google.com/stackdriver/docs
https://cloud.google.com/stackdriver/docs/solutions/agents/ops-agent/install-agent-vm-creation
Load Balancing in Kubernetes Engine
Load balancers distribute traffic and control access to a cluster. Services in Kubernetes
Engine can use external load balancers, internal load balancers, and HTTP(S) load balancers.
External load balancers are used when a service needs to be reachable from outside the
cluster and outside the VPC. GKE will provision a network load balancer for the service and
configure firewall rules to allow connections to the service from outside the cluster.
Internal load balancers are used when a service needs to be reachable from within the
cluster. In this case an internal TCP/UDP load balancer is used. The load balancer uses an IP
address from the VPC subnet instead of an external IP address.
Container native load balancing makes use of network endpoint groups (NEGs). The
endpoints consist of an IP address and a port that specify a pod and a container port.
To allow HTTP(S) traffic from outside the VPC, we use a Kubernetes Ingress resource.
The Ingress maps URLs and hostnames to services in the cluster. Services are configured to
use both ClusterIP and NodePort service types.
If further constraints on network are needed, you can specify network policies to limit
access to pods based on labels, IP address ranges, and port numbers. These policies create
pod-level
firewall rules. You can restrict External Load Balancers by specifying loadBalancerSourceRanges
in a service configuration. To limit access to HTTP(S) load balancers, use
Cloud Armor security policies and Identity-Aware
Proxy service.
https://cloud.google.com/kubernetes-engine/docs/concepts/service-load-balancerAbout LoadBalancer Services
Bucket locations
ou can select from the following location types:
A region is a specific geographic place, such as São Paulo.
A dual-region is a specific pair of regions, such as Tokyo and Osaka.
Dual-region pairings can be predefined or configurable.
A multi-region is a large geographic area, such as the United States, that contains two or more geographic places.
https://cloud.google.com/storage/docs/locations
