Google Kubernetes Engine – Networking

Google Kubernetes Engine – Networking

Kubernetes uses various IP ranges to assign IP addresses to nodes, Pods, and Services.

  • Node IP
    • Each node has an IP address assigned from the cluster’s VPC network.
    • Node IP provides connectivity from control components like kube-proxy and the kubelet to the Kubernetes API server.
    • Node IP is the node’s connection to the rest of the cluster.
  • Pod CIDR or Address Range
    • Each node has a pool of IP addresses that GKE assigns the Pods running on that node (a /24 CIDR block by default).
  • Pod Address
    • Each Pod has a single IP address assigned from the Pod CIDR range of its node.
    • Pod IP address is shared by all containers running within the Pod and connects them to other Pods running in the cluster.
  • Service Address Range
    • Each Service has an IP address, called the ClusterIP, assigned from the cluster’s VPC network.
  • For Standard clusters
    • a maximum of 110 Pods can run on a node with a /24 range, not 256 as you might expect. This provides a buffer so that Pods don’t become unschedulable due to a transient lack of IP addresses in the Pod IP range for a given node.
    • For ranges smaller than /24, roughly half as many Pods can be scheduled as IP addresses in the range.
  • Autopilot clusters can run a maximum of 32 Pods per node.

GKE Cluster Networking Types

  • GKE, clusters can be distinguished according to the way they route traffic from one Pod to another Pod.
  • VPC-native cluster: A cluster that uses alias IP address ranges
  • Routes-based cluster: A cluster that uses custom static routes in a VPC network

VPC-Native Clusters

  • VPC-native cluster uses alias IP address ranges
  • VPC-native is the recommended network mode for new clusters
  • VPC-native clusters have several benefits:
    • Pod IP addresses are natively routable within the cluster’s VPC network and other VPC networks connected to it by VPC Network Peering.
    • Pod IP address ranges, and subnet secondary IP address ranges in general, are accessible from on-premises networks connected with Cloud VPN or Cloud Interconnect using Cloud Routers.
    • Pod IP addresses are reserved in the VPC network before the Pods are created in the cluster. This prevents conflict with other resources in the VPC network and allows you to better plan IP address allocations.
    • Pod IP address ranges do not depend on custom static routes and do not consume the system-generated and custom static routes quota. Instead, automatically generated subnet routes handle routing for VPC-native clusters.
    • Firewall rules can be created that apply to just Pod IP address ranges instead of any IP address on the cluster’s nodes.

VPC-Native Clusters IP Allocation

GKE VPC-Native Cluster IP Management

  • VPC-Native cluster uses three unique subnet IP address ranges
    • Subnet’s primary IP address range for all node IP addresses.
      • Node IP addresses are assigned from the primary IP address range of the subnet associated with the cluster.
      • Both node IP addresses and the size of the subnet’s secondary IP address range for Pods limit the number of nodes that a cluster can support
    • One secondary IP address range for all Pod IP addresses.
      • Pod IP addresses are taken from the cluster subnet’s secondary IP address range for Pods.
      • By default, GKE allocates a /24 alias IP range (256 addresses) to each node for the Pods running on it.
      • On each node, those 256 alias IP addresses support up to 110 Pods.
      • Pod Address Range cannot be changed. If exhausted,
        • a new cluster with a larger Pod address range must be created or
        • node pools should be recreated after decreasing the --max-pods-per-node for the node pools.
    • Another secondary IP address range for all Service (cluster IP) addresses.
      • Service (cluster IP) addresses are taken from the cluster’s subnet’s secondary IP address range for Services.
      • Service address range should be large enough to provide addresses for all the Kubernetes Services hosted in the cluster.
  • Node, Pod, and Services IP address ranges must all be unique and subnets with overlapping primary and secondary IP address cannot be created

Routes-based Cluster

  • Routes-based cluster that uses custom static routes in a VPC network i.e. it uses Google Cloud Routes to route traffic between nodes
  • In a routes-based cluster
    • each node is allocated a /24 range of IP addresses for Pods.
    • With a /24 range, there are 256 addresses, but the maximum number of Pods per node is 110.
    • With approximately twice as many available IP addresses as possible Pods, Kubernetes is able to mitigate IP address reuse as Pods are added to and removed from a node.
  • Routes-based cluster uses two unique subnet IP address ranges
    • Subnet’s primary IP address range for all node IP addresses.
      • Node IP addresses are taken from the primary range of the cluster subnet
      • Cluster subnet must be large enough to hold the total number of nodes in your cluster.
    • Pod address range
      • A routes-based cluster has a range of IP addresses that are used for Pods and Services
      • Last /20 (4096 addresses) of the Pod address range is used for Services and the rest of the range is used for Pods
      • Pod address range size cannot be changed after cluster creation. So ensure that a large enough Pod address range is chosen to accommodate the cluster’s anticipated growth during cluster creation
  • Maximum number of nodes, Pods, and Services for a given GKE cluster is determined by the size of the cluster subnet and the size of the Pod address range.

Google Cloud NAT

Google Cloud NAT

  • Cloud NAT allows VM instances without external IP addresses and private GKE clusters send outbound packets to the internet and receive any corresponding established inbound response packets.
  • Cloud NAT is a distributed, software-defined managed service. It’s not based on proxy VMs or appliances.
  • Cloud NAT allows outbound and established inbound responses to those connections
  • Cloud NAT provides source network address translation (SNAT) for VMs without external IP addresses and destination network address translation (DNAT) for established inbound response packets.
  • Cloud NAT does not implement inbound connections from the internet. DNAT is only performed for packets that arrive as responses to outbound packets.
  • Cloud NAT works only for the VM’s network interface’s primary IP address and alias IP address provided that the network interface doesn’t have an external IP address assigned to it, in which case its routed through internet gateway.
  • Cloud NAT gateway is associated with a single VPC network, region, and Cloud Router
  • Cloud NAT provides the following benefits:
    • Security
      • Reduce the need for individual VMs to each have external IP addresses. Subject to egress firewall rules, VMs without external IP addresses can access destinations on the internet.
      • With manual NAT IP address assignment, whitelisting can be performed by the destination service to allow connections from known external IP addresses.
    • Availability
      • is a distributed, software-defined managed service.
      • Can be configured on a Cloud Router, which provides the control plane for NAT, holding specified configuration parameters
    • Scalability
      • can be configured to automatically scale the number of NAT IP addresses that it uses, and it supports VMs that belong to managed instance groups, including those with autoscaling enabled.
    • Performance
      • does not reduce the network bandwidth per VM.

Traditional NAT versus Cloud NAT (click to enlarge).

Cloud NAT Specifications

  • Cloud NAT gateway provides NAT services for packets sent from a VM’s network interface as long as that network interface doesn’t have an external IP address assigned to it
  • Cloud NAT gateway can be configured to provide NAT for the VM network interface’s primary internal IP address, alias IP ranges, or both
  • Cloud NAT gateway does not change the amount of outbound or inbound bandwidth that a VM can use, as it depends on VM’s machine type
  • Cloud NAT gateway can only apply to a single network interface of a VM.
  • Cloud NAT gateway can only use routes whose next hops are the default internet gateway
  • Cloud NAT never performs NAT for traffic sent to the select external IP addresses for Google APIs and services
  • Cloud NAT gateways are associated with subnet IP address ranges in a single region and a single VPC network.
  • Cloud NAT gateway created in one VPC network cannot provide NAT to VMs in other VPC networks connected by using VPC Network Peering, even if the VMs in peered networks are in the same region as the gateway.

References

Google_Cloud_NAT

Google Cloud CDN – Content Delivery Network

Google Cloud CDN

  • Google Cloud CDN (Content Delivery Network) caches website and application content closer to the user
  • Cloud CDN uses Google’s global edge network to serve content closer to users, which accelerates the websites and applications.
  • Cloud CDN works with external HTTP(S) Load Balancing to deliver content to the users.
  • Cloud CDN content can be sourced from various types of backends (also referred to as origin servers) :
    • Instance groups
    • Zonal network endpoint groups (NEGs)
    • Serverless NEGs: One or more App Engine, Cloud Run, or Cloud Functions services
    • Internet NEGs, for endpoints that are outside of Google Cloud (also known as custom origins)
    • Buckets in Cloud Storage
  • Cloud CDN with Google Cloud Armor enforces security policies only for requests for dynamic content, cache misses, or other requests that are destined for the origin server. Cache hits are served even if the downstream Google Cloud Armor security policy would prevent that request from reaching the origin server.

Cloud CDN Flow

Google Cloud CDN Response Flow

  • When a user requests content from an external HTTP(S) load balancer, the request arrives at a Google Front End (GFE), which is at the edge of Google’s network as close as possible to the user.
  • GFE uses Cloud CDN if the load balancer’s URL map routes traffic to a backend service or backend bucket that has Cloud CDN configured
  • Cloud CDN doesn’t perform any URL redirection. The Cloud CDN cache is located at the GFE.
  • Caching happens automatically for all cacheable content, once Cloud CDN is enabled
  • Cache Hits and Cache Misses
    • A cache is a group of servers that stores and manages content so that future requests for that content can be served faster.
    • Cached content is a copy of cacheable content that is stored on origin servers.
    • Cache Hit – GFE sends the cached response, if the GFE looks in the Cloud CDN cache and finds a cached response to the user’s request
    • Cache Miss – GFE determines that it can’t fulfill the request from the cache, if the content is requested first time or expired or evicated
  • Cache Hit Ratio
    • Cache Hit Ration is the percentage of times that a requested object is served from the cache
  • Cache Egress and Cache Fill
    • Cache Egress – Data transfer from a cache to the client
    • Cache Fill – Data transfer to a cache
  • Cache Eviction
    • Cloud CDN removes or evicts content to insert new content once the it reaches its capacity
    • Content evicted is usually the one that hasn’t recently been accessed, regardless of the content’s expiration time
  • Cache Expiration
    • Content in HTTP(S) caches can have a configurable expiration time or Time To Live (TTL)
  • Cache Invalidation
    • Cache Invalidation allows one to force an object or set of objects to be ignored by the cache
    • Invalidations don’t affect cached copies in web browser caches or caches operated by third-party internet service providers.
    • Invalidations are rate-limited and use patterns to control the same for e.g. use /images/* instead of each request for /images/1.jpg etc.
  • Cache Preloading
    • Caching is reactive in that an object is stored in a particular cache only if a request goes through that cache and if the response is cacheable.
    • Caches cannot be preloaded except by causing the individual caches to respond to requests.
  • An object stored in one cache does not automatically replicate into other caches; cache fill happens only in response to a client-initiated request.

Cloud CDN Best Practices

  • Cache static content
  • Use proper expiration time or TTL for time sensitive data
  • Use custom cache keys to improve cache hit ratio
    • Cloud CDN, by default, uses entire request URL to build the cache key
    • Cache keys can be customized to include or omit any combination of protocol, host, and query string
  • Use versioning to update content instead of cache invalidation
    • Versioning content serves a different version of the same content, effectively removing it by showing users new content before the cache entry expires
    • Invalidation is eventually consistent and should be used as a last resort

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

References

Google_Cloud_CDN

Google Cloud Compute Engine Snapshots

Compute Engine Snapshots

  • Snapshots provide periodic backup of the persistent disks
  • Snapshots incrementally back up data from the persistent disks.
  • Snapshots are global resources, so any snapshot is accessible by any resource within the same project.
  • Snapshots can be shared across projects.
  • Storage costs for persistent disk snapshots charge only for the total size of the snapshot.
  • Snapshots once created with the current state of the disk, can be restored as a new disk.
  • Compute Engine stores multiple copies of each snapshot across multiple locations with automatic checksums to ensure the integrity of the data.
  • Snapshots can be created from disks even while they are attached to running virtual machine (VM) instances.
  • Lifecycle of a snapshot created from a disk attached to a running VM instances is independent of the lifecycle of the VM instance.
  • Snapshots can be stored in either one Cloud Storage multi-regional location, such as asia, or one Cloud Storage regional location, such as asia-south1.
  • A multi-regional storage location provides higher availability and might reduce network costs when creating or restoring a snapshot
  • A snapshot can be used to create a new disk in any region and zone, regardless of the storage location of the snapshot.

Snapshot Creation

  • Snapshots are incremental and automatically compressed, so that they can be regularly created on a persistent disk faster and at a lower cost than regularly creating a full image of the disk.
  • Incremental snapshots work as follows:
    • The first successful snapshot of a persistent disk is a full snapshot that contains all the data on the persistent disk.
    • The second snapshot only contains any new data or modified data since the first snapshot. Data that hasn’t changed since snapshot 1 isn’t included. Instead, snapshot 2 contains references to snapshot 1 for any unchanged data.
    • Snapshot 3 contains any new or changed data since snapshot 2 but won’t contain any unchanged data from snapshot 1 or 2. Instead, snapshot 3 contains references to blocks in snapshot 1 and snapshot 2 for any unchanged data.

Snapshot Deletion

  • Compute Engine uses incremental snapshots so that each snapshot contains only the data that has changed since the previous snapshot.
  • For unchanged data, snapshots reference the data in previous snapshots.
  • When a snapshot is deleted, Compute Engine immediately marks the snapshot as DELETED in the system.
    • If the snapshot has no dependent snapshots, it is deleted outright.
    • However, if the snapshot does have dependent snapshots:
      • Any data that is required for restoring other snapshots is moved into the next snapshot, increasing its size.
      • Any data that is not required for restoring other snapshots is deleted. This lowers the total size of all your snapshots.
      • The next snapshot no longer references the snapshot marked for deletion, and instead references the snapshot before it.
  • Deleting a snapshot does not necessarily delete all the data on the snapshot because subsequent snapshots might require information stored in a previous snapshot, keep in mind that
  • To definitively delete data from the snapshots, you should delete all snapshots.

Snapshot Best Practices

  • If a snapshot is created of the persistent disk while the application is running, the snapshot might not capture pending writes that are in transit from memory to disk. So, prepare disk for consistency
    • Pause application/processes that write data, flush disk buffers
    • Unmount disk completely
    • For windows, use VSS snapshots
    • Use ext4 for linux to reduce the risk that data is cached without actually being written to the persistent disk.
  • Take only one snapshot at a time
  • Schedule snapshot off-peak hours
  • Avoid frequent snapshots, take a snapshot of the disk once per hour. Avoid taking snapshots more often than that. Disk snapshots can be created at most once every 10 minutes.
  • Use snapshot schedules as a best practice to back up your Compute Engine workloads
  • Use multiple persistent disks for large data volume. Larger amounts of data create larger snapshots, which cost more and take longer to create.
  • Run fstrim before snapshot (Linux) to clean up space, as this command removes blocks that the file system no longer needs, so that the system can create the snapshot more quickly and with a smaller size
  • Use image from an infrequently used snapshot, instead of using the snapshot itself

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You have a workload running on Compute Engine that is critical to your business. You want to ensure that the data on the boot disk of this workload is backed up regularly. You need to be able to restore a backup as quickly as possible in case of disaster. You also want older backups to be cleaned automatically to save on cost. You want to follow Google-recommended practices. What should you do?
    1. Create a Cloud Function to create an instance template.
    2. Create a snapshot schedule for the disk using the desired interval.
    3. Create a cron job to create a new disk from the disk using gcloud.
    4. Create a Cloud Task to create an image and export it to Cloud Storage.

References

Google_Cloud_Compute_Engine_Snapshots

Google Cloud Compute Engine Storage Options

Google Cloud Compute Engine Storage Options

Persistent Disk

  • Persistent disks are durable network storage devices that the instances can access like physical disks in a desktop or a server.
  • Data on each persistent disk is distributed across several physical disks.
  • Compute Engine manages the physical disks and the data distribution to ensure redundancy and optimal performance.
  • Persistent disks are located independently from the VM instances and can be detached or moved to keep the data even after the instance is deleted
  • Persistent disk performance scales automatically with size, so they can be resized or additional ones added to meet the performance and storage space requirements.

Persistent Disk Types

  • Standard persistent disks (pd-standard) are backed by standard hard disk drives (HDD).
  • Balanced persistent disks (pd-balanced) are backed by solid-state drives (SSD). They are an alternative to SSD persistent disks that balance performance and cost.
  • SSD persistent disks (pd-ssd) are backed by solid-state drives (SSD).

Zonal Persistent Disks

  • Zonal persistent disks provide durable storage and replication of data within a single zone in a region.
  • Persistent disks have built-in redundancy to protect the data against equipment failure and to ensure data availability through datacenter maintenance events.
  • For additional space on the persistent disks, resize the disks and resize the single file system rather than repartitioning and formatting.
  • Compute Engine automatically encrypts the data in transit, before it travels outside of the instance to persistent disk storage space.
  • Zonal persistent disk remains encrypted either with system-defined keys or with customer-supplied keys.

Regional Persistent Disks

  • Regional persistent disks provide durable storage and replication of data between two zones in the same region.
  • Regional persistent disks are also designed to work with regional managed instance groups.
  • Zonal outage can be handled by force attaching the disk to the standby instance, even if the disk can’t be detached from the original VM
  • Regional persistent disks are designed for
    • workloads that require a lower RPO and RTO compared to using persistent disk snapshots.
    • write performance is less critical than data redundancy across multiple zones.
  • Regional persistent disks cannot be used with memory-optimized machines and compute-optimized machines.

Local SSD

  • Local SSDs are physically attached to the server that hosts the VM instance.
  • Local SSDs have higher throughput and lower latency than standard persistent disks or SSD persistent disks.
  • Data stored on a local SSD persists only until the instance is stopped or deleted.
  • Local SSDs performance gains require certain trade-offs in availability, durability, and flexibility. Because of these trade-offs, Local SSD storage isn’t automatically replicated and all data on the local SSD might be lost if the instance terminates for any reason.
  • Each local SSD is 375 GB in size, but a maximum of 24 local SSD partitions can be attached for a total of 9 TB per instance.
  • Compute Engine automatically encrypts the data when it is written to local SSD storage space. Customer-supplied encryption keys is not supported with local SSDs.

Cloud Storage Buckets

  • Cloud Storage buckets are the most flexible, scalable, and durable storage option for the VM instances.
  • Cloud Storage is ideal if you don’t require the lower latency of Persistent Disks and Local SSDs, and can store the data in a Cloud Storage bucket.
  • Performance of Cloud Storage depends on the selected storage class
  • Standard storage class used in the same location as the instance gives performance that is comparable to persistent disks but with higher latency and less consistent throughput characteristics.
  • Cloud Storage buckets have built-in redundancy to protect the data against equipment failure and to ensure data availability through datacenter maintenance events
  • Cloud Storage buckets aren’t restricted to the zone where the instance is located. Multiregional Cloud Storage buckets stores the data redundantly across at least two regions within a larger multiregional location.
  • Cloud Storage bucket can be mounted on the instance as file system
  • Cloud Storage allows read and write data to a bucket from multiple instances simultaneously.
  • However, Cloud Storage buckets are object stores that don’t have the same write constraints as a POSIX file system and can’t be used as boot disks. Multiple instances working on the same file can lead to overwritten data.
  • Cloud Storage supports both encryption at rest and in transit.

Filestore

  • Filestore provides high-performance, fully managed network attached Storage (NAS)  file storage

Storage Options Comparison

Google Cloud Compute Engine Storage Options

Storage Options Performance Comparison

Google Cloud Compute Engine Storage Performance

References

Google Cloud Router

Google Cloud Router

  • Cloud Router is a fully distributed and managed service that programs custom dynamic routes and scales with the network traffic.
  • Cloud Router works with both legacy networks and VPC networks.
  • Cloud Router isn’t a connectivity option, but a service that works over Cloud VPN or Interconnect connections to provide dynamic routing by using the Border Gateway Protocol (BGP) for the VPC networks.
  • Cloud Router isn’t supported for Direct Peering or Carrier Peering connections.
  • Cloud Router isn’t a physical device that might cause a bottleneck, and it can’t be used by itself.
  • Cloud Router is required or recommended in the following cases:
    • Required for Cloud NAT
    • Required for Cloud Interconnect and HA VPN
    • A recommended configuration option for Classic VPN.
  • Cloud Router helps dynamically exchange routes between the Google Cloud networks and the on-premises network.
  • Cloud Router peers with the on-premises VPN gateway or router to provide dynamic routing and exchanges topology information through BGP.
  • Cloud Router frees you from maintaining static routes
  • Google Cloud recommend creating two Cloud Routers in each region for a Cloud Interconnect for 99.99% availability.
  • Cloud Router supports following dynamic routing mode
    • Regional routing mode – provides visibility to resources only in the defined region.
    • Global routing mode – provides has visibility to resources in all regions

Google Cloud Router - Global Dynamic Routing

References

Google_Cloud_Router

Google Cloud Data Transfer Services

Google Cloud Data Transfer Services

  • Google Cloud Data Transfer services provide various options in terms of network and transfer tools to help transfer data from on-premises to Google Cloud network

Network Services

Cloud VPN

  • Provides network connectivity with Google Cloud between on-premises network and Google Cloud, or from Google Cloud to another cloud provider.
  • Cloud VPN still routes the traffic through Internet.
  • Cloud VPN is quick to setup (as compared to Interconnect)
  • Each Cloud VPN tunnel can support up to 3 Gbps total for ingress and egress, but available bandwidth depends on the connectivity
  • Choose Cloud VPN to encrypt traffic to Google Cloud, or with lower throughput solution, or experimenting with migrating the workloads to Google Cloud
  • Cloud Interconnect offers a direct connection to Google Cloud through Google or one of the Cloud Interconnect service providers.
  • Cloud Interconnect service prevents data from going on the public internet and can provide a more consistent throughput for large data transfers
  • For enterprise-grade connection to Google Cloud that has higher throughput requirements, choose Dedicated Interconnect (10 Gbps to 100 Gbps) or Partner Interconnect (50 Mbps to 50 Gbps)
  • Cloud Interconnect provides access to all Google Cloud products and services from your on-premises network except Google Workspace.
  • Cloud Interconnect also allows access to supported APIs and services by using Private Google Access from on-premises hosts.
  • Direct Peering provides access to the Google network with fewer network hops than with a public internet connection
  • By using Direct Peering, internet traffic is exchanged between the customer network and Google’s Edge Points of Presence (PoPs), which means the data does not use the public internet.

Google Cloud Networking Services Decision Tree

Google Cloud Hybrid Connectivity

Transfer Services

gsutil

  • gsutil tool is the standard tool for small- to medium-sized transfers (less than 1 TB) over a typical enterprise-scale network, from a private data center to Google Cloud.
  • gsutil provides all the basic features need to manage the Cloud Storage instances, including copying the data to and from the local file system and Cloud Storage.
  • gsutil can also move, rename and remove objects and perform real-time incremental syncs, like rsync, to a Cloud Storage bucket.
  • gsutil is especially useful in the following scenarios:
    • as-needed transfers or during command-line sessions by your users.
    • transferring only a few files or very large files, or both.
    • consuming the output of a program (streaming output to Cloud Storage)
    • watch a directory with a moderate number of files and sync any updates with very low latencies.
  • gsutil provides following features
    • Parallel multi-threaded transfers with  gsutil -m, increasing transfer speeds.
    • Composite transfers for a single large file to break them into smaller chunks to increase transfer speed. Chunks are transferred and validated in parallel, sending all data to Google. Once the chunks arrive at Google, they are combined (referred to as compositing) to form a single object
  • Storage Transfer Service is a fully managed, highly scalable service to automate transfers from other public clouds into Cloud Storage.
  • Storage Transfer Service for Cloud-to-Cloud transfers
    • supports transfers into Cloud Storage from S3 and HTTP.
    • supports daily copies of any modified objects.
    • doesn’t currently support data transfers to S3.
  • Storage Transfer Service also supports data transfers for on-premises data transfers from network file system (NFS) storage to Cloud Storage.
  • Storage Transfer Service for on-premises data
    • is designed for large-scale transfers (up to petabytes of data, billions of files).
    • supports full copies or incremental copies
    • can be setup by installing  on- premises software (known as agents) onto computers in the data center.
  • has a simple, managed graphical user interface; even non-technically savvy users (after setup) can use it to move data.
  • provides robust error-reporting and a record of all files and objects that are moved.
  • supports executing recurring transfers on a schedule.

Transfer Appliance

  • Transfer Appliance is an excellent option for performing large-scale transfers, especially when a fast network connection is unavailable, it’s too costly to acquire more bandwidth or its one time transfer
  • Expected turnaround time for a network appliance to be shipped, loaded with the data, shipped back, and rehydrated on Google Cloud is 50 days.
  • If the online transfer timeframe is calculated to be substantially more than this timeframe, consider Transfer Appliance.
  • Transfer Appliance requires ability to receive and ship back the Google-owned hardware.
  • Transfer Appliance is available only in certain countries.

Transfer Data vs Speed Comparison

Data Migration Speeds

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company wants to connect cloud applications to an Oracle database in its data center. Requirements are a maximum of 9 Gbps of data and a Service Level Agreement (SLA) of 99%. Which option best suits the requirements?
    1. Implement a high-throughput Cloud VPN connection
    2. Cloud Router with VPN
    3. Dedicated Interconnect
    4. Partner Interconnect

References

 

Google Cloud VPN

Google Cloud VPN

  • Cloud VPN securely connects your peer network to the Virtual Private Cloud (VPC) network through an IPsec VPN connection.
  • Traffic traveling between the two networks is encrypted by one VPN gateway and then decrypted by the other VPN gateway.
  • Cloud VPN protects the data as it travels over the internet.
  • Two instances of Cloud VPN can also be connected to each other.

Cloud VPN Specifications

  • only supports site-to-site IPsec VPN connectivity
  • does not support client-to-gateway scenarios i.e. Cloud VPN doesn’t support use cases where client computers need to “dial in” to a VPN by using client VPN software.
  • only supports IPsec. Other VPN technologies (such as SSL VPN) are not supported.
  • can be used with Private Google Access for on-premises hosts
  • Each Cloud VPN gateway must be connected to another Cloud VPN gateway or a peer VPN gateway.
  • Peer VPN gateway must have a static external (internet routable) IPv4 address, needed to configure Cloud VPN.
  • requires that the peer VPN gateway be configured to support prefragmentation. Packets must be fragmented before being encapsulated.
  • Each Cloud VPN tunnel can support up to 3 gigabits per second (Gbps) total for ingress and egress.

Cloud VPN Components

  • Cloud VPN gateway
    • A virtual VPN gateway running in Google Cloud managed by Google, using a specified configuration in the project, and used only by you.
    • Each Cloud VPN gateway is a regional resource that uses one or more regional external IP addresses.
    • A Cloud VPN gateway can connect to a peer VPN gateway.
  • Peer VPN gateway
    • A gateway that is connected to a Cloud VPN gateway.
    • A peer VPN gateway can be one of the following:
      • Another Cloud VPN gateway
      • A VPN gateway hosted by another cloud provider such as AWS or Microsoft Azure
      • An on-premises VPN device or VPN service
  • External VPN gateway
    • A gateway resource configured for HA VPN that provides information to Google Cloud about the peer VPN gateway or gateways.
  • Remote peer IP address
    • For an HA VPN gateway interface that connects to an external VPN gateway, the remote peer IP address is the IP address of the interface on the external VPN gateway that is used for the tunnel.
  • VPN tunnel
    • A VPN tunnel connects two VPN gateways and serves as a virtual medium through which encrypted traffic is passed.
  • Internet Key Exchange (IKE)
    • IKE is the protocol used for authentication and to negotiate a session key for encrypting traffic.

Cloud VPN HA

  • Cloud VPN HA provides high-available and secure connection between the on-premises and the VPC network through an IPsec VPN connection in a single region
  • HA VPN provides an SLA of 99.99% service availability, when configured with two interfaces and two external IP addresses.
  • Cloud VPN supports creation of multiple HA VPN gateways and each of the HA VPN gateway interfaces supports multiple tunnels
  • Peer VPN gateway device must support dynamic (BGP) routing.

Google Cloud VPN HA

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your company’s infrastructure is on-premises, but all machines are running at maximum capacity. You want to burst to Google
    Cloud. The workloads on Google Cloud must be able to directly communicate to the workloads on-premises using a private IP
    range. What should you do?

    1. In Google Cloud, configure the VPC as a host for Shared VPC.
    2. In Google Cloud, configure the VPC for VPC Network Peering.
    3. Create bastion hosts both in your on-premises environment and on Google Cloud. Configure both as proxy servers using
      their public IP addresses.
    4. Set up Cloud VPN between the infrastructure on-premises and Google Cloud.

Related Reads

References

Google Cloud Services Cheat Sheet

Google Certification Exam Cheat Sheet

Google Certification Exams cover a lot of topics and a wide range of services with minute details for features, patterns, anti patterns and their integration with other services. This blog post is just to have a quick summary of all the services and key points for a quick glance before you appear for the exam

Google Services

GCP Marketplace (Cloud Launcher)

  • GCP Marketplace offers ready-to-go development stacks, solutions, and services to accelerate development and spend less time installing and more time developing.
    • Deploy production-grade solutions in a few clicks
    • Single bill for all your GCP and 3rd party services
    • Manage solutions using Deployment Manager
    • Notifications when a security update is available
    • Direct access to partner support

References

Google_Cloud_Services

Google Cloud Networking Services Cheat Sheet

Virtual Private Cloud

  • Virtual Private Cloud (VPC) provides networking functionality for the cloud-based resources and services that is global, scalable, and flexible.
  • VPC networks are global resources, including the associated routes and firewall rules, and are not associated with any particular region or zone.
  • Subnets are regional resources and each subnet defines a range of IP addresses
  • Network firewall rules
    • control the Traffic to and from instances.
    • Rules are implemented on the VMs themselves, so traffic can only be controlled and logged as it leaves or arrives at a VM.
    • Firewall rules are defined to allow or deny traffic and are executed with in order with a defined priority
    • Highest priority (lower integer) rule applicable to a target for a given type of traffic takes precedence
  • Resources within a VPC network can communicate with one another by using internal IPv4 addresses, subject to applicable network firewall rules.
  • Private access options for services allow instances with internal IP addresses can communicate with Google APIs and services.
  • Shared VPC to keep a VPC network in a common host project shared with service projects. Authorized IAM members from other projects in the same organization can create resources that use subnets of the Shared VPC network
  • VPC Network Peering allow VPC networks to be connected with other VPC networks in different projects or organizations.
  • VPC networks can be securely connected in hybrid environments by using Cloud VPN or Cloud Interconnect.
  • Primary and Secondary IP address cannot overlap with the on-premises CIDR
  • VPC networks only support IPv4 unicast traffic. They do not support broadcast, multicast, or IPv6 traffic within the network; VMs in the VPC network can only send to IPv4 destinations and only receive traffic from IPv4 sources.
  • VPC Flow Logs records a sample of network flows sent from and received by VM instances, including instances used as GKE nodes.

Cloud Load Balancing

  • Cloud Load Balancing is a fully distributed, software-defined managed load balancing service
  • distributes user traffic across multiple instances of the applications and reduces the risk that the of performance issues for the applications experience by spreading the load
  • provides health checking mechanisms that determine if backends, such as instance groups and zonal network endpoint groups (NEGs), are healthy and properly respond to traffic.
  • supports IPv6 clients with HTTP(S) Load Balancing, SSL Proxy Load Balancing, and TCP Proxy Load Balancing.
  • supports multiple Cloud Load Balancing types
    • Internal HTTP(S) Load Balancing
      • is a proxy-based, regional Layer 7 load balancer that enables running and scaling services behind an internal IP address.
      • supports a regional backend service, which distributes HTTP and HTTPS requests to healthy backends (either instance groups containing CE VMs or NEGs containing GKE containers).
      • supports path based routing
      • preserves the Host header of the original client request and also appends two IP addresses (Client and LB )to the X-Forwarded-For header
      • supports a regional health check that periodically monitors the readiness of the backends.
      • has native support for the WebSocket protocol when using HTTP or HTTPS as the protocol to the backend
    • External HTTP(S) Load Balancing
      • is a global, proxy-based Layer 7 load balancer that enables running and scaling the services worldwide behind a single external IP address
      • distributes HTTP and HTTPS traffic to backends hosted on Compute Engine and GKE
      • offers global (cross-regional) and regional load balancing
      • supports content-based load balancing using URL maps
      • preserves the Host header of the original client request and also appends two IP addresses (Client and LB) to the X-Forwarded-For header
      • supports connection draining on backend services
      • has native support for the WebSocket protocol when using HTTP or HTTPS as the protocol to the backend
      • does not support client certificate-based authentication, also known as mutual TLS authentication.
    • Internal TCP/UDP Load Balancing
      • is a managed, internal, pass-through, regional Layer 4 load balancer that enables running and scaling services behind an internal IP address
      • distributes traffic among VM instances in the same region in a Virtual Private Cloud (VPC) network by using an internal IP address.
      • provides high-performance, pass-through Layer 4 load balancer for TCP or UDP traffic.
      • routes original connections directly from clients to the healthy backends, without any interruption.
      • does not terminate SSL traffic and SSL traffic can be terminated by the backends instead of by the load balancer
      • provides access through VPC Network Peering, Cloud VPN or Cloud Interconnect
      • supports health check that periodically monitors the readiness of the backends.
    • External TCP/UDP Network Load Balancing
      • is a managed, external, pass-through, regional Layer 4 load balancer that distributes TCP or UDP traffic originating from the internet to among VM instances in the same region
      • Load-balanced packets are received by backend VMs with their source IP unchanged.
      • Load-balanced connections are terminated by the backend VMs. Responses from the backend VMs go directly to the clients, not back through the load balancer.
      • scope of a network load balancer is regional, not global. A network load balancer cannot span multiple regions. Within a single region, the load balancer services all zones.
      • supports connection tracking table and a configurable consistent hashing algorithm to determine how traffic is distributed to backend VMs.
      • does not support Network endpoint groups (NEGs) as backends
    • External SSL Proxy Load Balancing
      • is a reverse proxy load balancer that distributes SSL traffic coming from the internet to VM instances in the VPC network.
      • with SSL traffic, user SSL (TLS) connections are terminated at the load balancing layer, and then proxied to the closest available backend instances by using either SSL (recommended) or TCP.
      • supports global load balancing service with the Premium Tier
        supports regional load balancing service with the Standard Tier
      • is intended for non-HTTP(S) traffic. For HTTP(S) traffic, GCP recommends using HTTP(S) Load Balancing.
      • supports proxy protocol header to preserve the original source IP addresses of incoming connections to the load balancer
      • does not support client certificate-based authentication, also known as mutual TLS authentication.
    • External TCP Proxy Load Balancing
      • is a reverse proxy load balancer that distributes TCP traffic coming from the internet to VM instances in the VPC network
      • terminates traffic coming over a TCP connection at the load balancing layer, and then forwards to the closest available backend using TCP or SSL
      • use a single IP address for all users worldwide and automatically routes traffic to the backends that are closest to the user
      • supports global load balancing service with the Premium Tier
        supports regional load balancing service with the Standard Tier
      • supports proxy protocol header to preserve the original source IP addresses of incoming connections to the load balancer

Cloud CDN

  • caches website and application content closer to the user
  • uses Google’s global edge network to serve content closer to users, which accelerates the websites and applications.
  • works with external HTTP(S) Load Balancing to deliver content to the users
  • Cloud CDN content can be sourced from various types of backends
    • Instance groups
    • Zonal network endpoint groups (NEGs)
    • Serverless NEGs: One or more App Engine, Cloud Run, or Cloud Functions services
    • Internet NEGs, for endpoints that are outside of Google Cloud (also known as custom origins)
    • Buckets in Cloud Storage
  • Cloud CDN with Google Cloud Armor enforces security policies only for requests for dynamic content, cache misses, or other requests that are destined for the origin server. Cache hits are served even if the downstream Google Cloud Armor security policy would prevent that request from reaching the origin server.
  • recommends
    • using versioning instead of cache invalidation
    • using custom keys to improve cache hit ration
    • cache static content

Cloud VPN

  • securely connects the peer network to the VPC network through an IPsec VPN connection.
  • encrypts the data as it travels over the internet.
  • only supports site-to-site IPsec VPN connectivity and not client-to-gateway scenarios
  • only supports IPsec
  • can be used with Private Google Access for on-premises hosts
  • Cloud VPN HA
    • provides high-available and secure connection between the on-premises and the VPC network through an IPsec VPN connection in a single region
    • provides an SLA of 99.99% service availability, when configured with two interfaces and two external IP addresses.

Cloud Router

  • is a fully distributed, managed service that provides dynamic routing and scales with the network traffic.
  • works with both legacy networks and VPC networks.
  • isn’t supported for Direct Peering or Carrier Peering connections.
  • helps dynamically exchange routes between the Google Cloud networks and the on-premises network.
  • peers with the on-premises VPN gateway or router to provide dynamic routing and exchanges topology information through BGP.
  • Google Cloud recommend creating two Cloud Routers in each region for a Cloud Interconnect for 99.99% availability.
  • supports following dynamic routing mode
    • Regional routing mode – provides visibility to resources only in the defined region.
    • Global routing mode – provides has visibility to resources in all regions

Cloud VPN vs Dedicated Interconnect