Google Cloud Platform Blog: September 2017

Google Container Engine - Kubernetes 1.8 takes advantage of the cloud built for containers

Friday, September 29, 2017

By Dan Paik, Product Manager, Container EngineGoogle Container EngineGoogle Cloud Platform Speed and automation announcedthree zones within a regiontry out high availability clusters

Node Auto-Repair is in beta and opt-in. Container Engine can automatically repair your nodes using the Kubernetes Node Problem Detector to find common problems and proactively repair nodes and clusters.

Node Auto-Upgrade is generally available and opt-in. Cluster upgrades are a critical Day 2 task and to give you automation with full control, we now offer Maintenance Windows (beta) to specify when you want Container Engine to auto-upgrade your masters and nodes.

Custom metrics on the Horizontal Pod Autoscaler will soon be in beta so you can scale your pods on metrics other than CPU utilization. To setup HPA custom metrics on Kubernetes Engine, follow this tutorial.

Cluster Autoscaling is generally available with performance improvements enabling up to 1,000 nodes, with up to 30 pods in each node as well as letting you specify a minimum and maximum number of nodes for your cluster. This will automatically grows or shrinks your cluster depending on workload demands.

Container-native networking - Container Engine exclusive! - only on GCP

Aliased IP support is in beta. With aliased IP support, you can take advantage of several network enhancements and features, including support for connecting Container Engine clusters over a Peered VPC. Aliased IPs are available for new clusters only; support for migrating existing clusters will be added in an upcoming release.

Multi-cluster ingress will soon be in alpha. You will be able to construct highly available, globally distributed services by easily setting up Google Cloud Load Balancing to serve your end users from the closest Container Engine cluster. To apply for access, please fill out this form.

Shared VPC support will soon be in alpha. You will be able to create Container Engine clusters on a VPC shared by multiple projects in your cloud organization. To apply for access, please fill out this form.

Machine learning and hardware accelerationCUDASpark on Kubernetes

NVIDIA Tesla P100 GPUs are available in alpha clusters. In addition to the NVIDIA Tesla K80, you can now create a node with up to 4 NVIDIA P100 GPUs. P100 GPUs can accelerate your workloads by up to 10x compared to the K80! If you are interested in alpha testing your CUDA models in Container Engine, please sign up for the GPU alpha.

Cloud Storage is now accessible from Spark. Spark on Kubernetes can now communicate with Google BigQuery and Google Cloud Storage as data sources and sinks from Spark using bigdata-interop connectors.

CronJobs are now in beta so you can now schedule cron jobs such as data processing pipelines to run on a given schedule in your production clusters!

Extensibility

Ubuntu node image is now generally available. To offer more flexibility and choice, you can now select Ubuntu as your node image when creating a node. Container Optimized OS (COS) remains our default node image.

Custom Resource Definition (CRD) is a lightweight way to create API resource types in Kubernetes and make it easy to interact with custom controllers via kubectl. Please note that CRD replaces the now deprecated Third Party Resource (TPR) object.

Security and reliability

Role Based Access Control (RBAC) is now generally available. This feature allows a cluster administrator to specify fine-grained policies describing which users, groups, and service accounts are allowed to perform which operations on which API resources.

Network Policy Enforcement using Calico is in beta. Starting from Kubernetes 1.7.6, you can help secure your Container Engine cluster with network policy pod-to-pod ingress rules. Kubernetes 1.8 adds additional support for CIDR-based rules, allowing you to whitelist access to resources outside of your Kubernetes cluster (e.g., VMs, hosted services, and even public services), so that you can integrate your Kubernetes application with other IT services and investments. Additionally, you can also now specify pod-to-pod egress rules, providing tighter controls needed to ensure service integrity. Learn more about here.

Node Allocatable is generally available. Container Engine includes the Kubernetes Node Allocatable feature for more accurate resource management, providing higher node stability and reliability by protecting node components from out-of-resource issues.

Priority / Preemption is in alpha clusters. Container Engine implements Kubernetes Priority and Preemption so you can associate priority pods to priority levels such that you can preempt lower-priority pods to make room for higher-priority ones when you have more workloads ready to run on the cluster than there are resources available.

Enterprise-ready container operations - monitoring and management designed for Kubernetes Container Engine user interfaceStackdriverCloud Shell

Easier configurations: You can now view and edit your YAML files directly in the UI. We also added easy to use shortcuts for the most common user actions like rolling updates or scaling a deployment.

Node information details: Cluster view now shows details such as node health status, relevant logs, and pod information so you can easily troubleshoot your clusters and nodes.

Stackdriver Monitoring integration: Your workload views now include charts showing CPU, memory, and disk usage. We also link to corresponding Stackdriver pages for a more in-depth look.

Cloud Shell integration: You can now generate and execute exact kubectl commands directly in the browser. No need to manually switch context between multiple clusters and namespaces or copy and paste. Just hit enter!

Cluster recommendations: Recommendations in cluster views suggest ways that you can improve your cluster, for example, turning on autoscaling for underutilized clusters or upgrading nodes for version alignment.

Audit LoggingCloud Audit LoggingAudit Logging early access program
Container Engine everywhere GCP regions

Mixpanel “All of our applications and our primary database now run on Google Container Engine. Container Engine gives us elasticity and scalable performance for our Kubernetes clusters. It’s fully supported and managed by Google, which makes it more attractive to us than elastic container services from other cloud providers,” says Arya Asemanfar, Engineering Manager at Mixpanel. RealMassive “What it comes down to for us is speed-to-market and cost. With Google Cloud Platform, we can confidently release services multiple times a day and launch new markets in a day. We’ve also reduced our cloud hosting costs by 50% by moving to microservices on Google Container Engine,” says Jason Vertrees, CTO at RealMassive. Bitnamiprivate Kubernetes cluster Try it today! please join our early access programContainer Engine release noteswebsitefree trial

Introducing Network Policy support for Google Container Engine, with Project Calico and Tigera

Friday, September 29, 2017

By Andy Randall, Co-founder and VP Product, Partners & Customer Success, Tigera[Editor’s Note: Today we announced the beta of Kubernetes Network Policy in Google Container Engine, a feature we implemented in close collaboration with our partner Tigera, the company behind Project Calico. Read on for more details from Tigera co-founder and vice president of product, Andy Randall.]configure firewall rules on VPC networksGoogle Container EngineMicro-segmentation in the Cloud Native World Kubernetes Network Policy 1.0Kubernetes documentation

Network policies are defined by the NetworkPolicy resource type. These are applied to the Kubernetes API server like any other resource (e.g., kubectl apply -f my-network-policy.yaml).

By default, all pods in a namespace allow unrestricted access. That is, they can accept incoming network connections from any source.

A NetworkPolicy object contains a selector expression (“podSelector”) that selects a set of pods to which the policy applies, and the rules about which incoming connections will be allowed (“ingress” rules). Ingress rules can be quite flexible, including their own namespace selector or pod selector expressions.

Policies apply to a namespace. Every pod in that namespace selected by the policy’s podSelector will have the ingress rules applied, so any connection attempts that are not explicitly allowed are rejected. Calico enforces this policy extremely efficiently using iptables rules programmed into the underlying host’s kernel.

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy spec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379
In this case, the policy is called “test-network-policy” and applies to the default namespace. It restricts inbound connections to every pod in the default namespace that has the label “role: db” applied. The selectors are disjunctive, i.e., either can be true. That means that connections can come from any pod in a namespace with label “project: myproject”, OR any pod in the default namespace with the label “role: frontend”. Further, these connections must be on TCP port 6379 (the standard port for Redis).

As you can see, Network Policy is an intent-based policy model, i.e., you specify your desired end-state and let the system ensure it happens. As pods are created and destroyed, or a label (such as “role: db”) is applied or deleted from existing pods, you don’t need to update anything: Calico automatically takes care of things behind the scenes and ensures that every pod on every host has the right access rules applied.

As you can imagine, that’s quite a computational challenge at scale, and Calico’s policy engine contains a lot of smarts to meet Container Engine’s production performance demands. The good news is that you don’t need to worry about that. Just apply your policies and Calico takes care of the rest.

Enabling Network Policy in Container Engine

For new and existing clusters running at least Kubernetes v1.7.6, you can enable network policy on Container Engine via the UI, CLI or API. For new clusters, simply set the flag (or check the box in the UI) when creating the cluster. For existing clusters there is a two-step process:

Enable the network policy add-on on the master.
Enable network policy for the entire cluster’s node-pools.

Here’s how to do that during cluster creation:

# Create a cluster with Network Policy Enabled gcloud beta container clusters create <CLUSTER> --project=<PROJECT_ID> --zone=&ltZONE> --enable-network-policy --cluster-version=1.7.6
Here’s how to do it for existing clusters:

# Create a cluster with Network Policy Enabled

# Enable the addon
gcloud beta container clusters update <CLUSTER> --project=<PROJECT_ID> 
--zone=<ZONE>--update-addons=NetworkPolicy=ENABLE

# Enable on nodes (This re-creates the node pools)
gcloud beta container clusters update <CLUSTER> --project=<PROJECT_ID> 
--zone=<ZONE> --enable-network-policy

Looking ahead

Applying egress rules (restricting which outbound connections a pod can make)

Referring to IP addresses or ranges within rules

Attend our joint webinar! Register here

PHP 7.1 for Google App Engine is generally available

Friday, September 29, 2017

By Brent Shaffer and Takashi Matsuo, Developer Programs Engineer, Google Cloud PlatformPHP 7.1 Google App Engine in betaGoogle App EngineApp Engine flexible environment Extension enablerany PHP extension that is stable (1.0 and above) and does not require a EULAPHP runtime pageComposercomposer require "ext-gd:*" --ignore-platform-reqscomposer.json{ "require": { "ext-gd": "*" } }extending the PHP runtime Stackdriver Logging and Error Reporting support

Stackdrivergoogle/cloudcomposer require google/cloudenable_stackdriver_integrationtrueruntime_configapp.yamlruntime_config: enable_stackdriver_integration: truebatch-processing daemonPsrBatchLoggeruse Google\Cloud\Logging\LoggingClient; use Psr\Log\LogLevel; $batchLogger = LoggingClient::psrBatchLogger('app'); // logName `app` // You now have a PSR-3 compliant logger! $batchLogger->log(LogLevel::DEBUG, 'This is a debug log'); $batchLogger->debug('This is a debug log'); // The same thingenable_stackdriver_integrationError Reportingthrow new \Exception('Uncaught exceptions are logged to Stackdriver!');$obj->thisDoesNotExist(); // Fatal errors are also logged to Stackdriver!google/cloud-logginggoogle/cloud-error-reporting--ignore-platform-reqsinstallation instructionscomposer require google/cloud-logging google/cloud-error-reporting \ "ext-grpc:*" --ignore-platform-reqs Stackdriver Logging for Laravelenable_stackdriver_integrationLaravelbootstrap/app.php// Add `Use` for logging libs use Google\Cloud\Logging\LoggingClient; use Monolog\Handler\PsrHandler; // ... other code // Just before returning $app if (isset($_SERVER['GAE_SERVICE'])) { $app->configureMonologUsing(function ($monolog) { $logger = LoggingClient::psrBatchLogger('app'); $handler = new PsrHandler($logger); $monolog->pushHandler($handler); }); } return $app;use Google\Cloud\ErrorReporting\Bootstrap; // .. other code public function report(Exception $exception) { if (isset($_SERVER['GAE_SERVICE'])) { Bootstrap::exceptionHandler($exception);< } else { parent::report($exception); } } gRPC SupportgRPCCloud Spannercomposer.jsoncomposer require "ext-grpc:*" google/cloud-spanner --ignore-platform-reqs<?php // index.php require __DIR__ . '/vendor/autoload.php'; $spanner = new Google\Cloud\Spanner\SpannerClient(); $instance = $spanner->instance('YOUR_INSTANCE_ID'); $database = $instance->database('YOUR_DATABASE_ID'); # Execute a simple SQL statement. echo $database->execute('SELECT "Hello Spanner" as test'); Our commitment to PHP and open source

https://github.com/GoogleCloudPlatform/php-docker

https://github.com/GoogleCloudPlatform/google-cloud-php

https://github.com/google/google-api-php-client

https://github.com/GoogleCloudPlatform/wordpress-plugins

https://github.com/grpc/grpc-php

https://github.com/census-instrumentation/opencensus-php

Twitterrequest an invite#PHP channel

Introducing nested virtualization for Google Compute Engine

Thursday, September 28, 2017

By Scott Van Woudenberg, Product Manager, Google Compute EngineGoogle Compute EngineIntel VT-x

machine typesPreemptible VMsregions and zonesScale ComputingappOrbit "This is a huge win for QA and development teams who need native mobile systems, such as Android, for testing/validating mobile apps. Using Google’s new hardware-accelerated nested virtualization, Functionize now enables QA teams to dramatically reduce costs, time-to-test, and the pain of maintaining a complex device inventory." -- Tamas Cser, Founder and CEO, Functionizenested virtualization documentationcontact usfree trial

How we built a brand new bank on GCP and Cloud Spanner: Shine

Thursday, September 28, 2017

By Raphael Simon, CTO and Co-Founder of Shine[Editor’s note: Technology today lets companies of any size take on entire industries simply with an innovative business model plus digital distribution. Take Shine, a French startup whose platform helps freelancers manage their finances -- and their administrative commitments. Here, Raphael Simon, Shine’s CTO and co-founder, talks about why Shine built a new bank on Google Cloud Platform, and in particular Cloud Spanner. Read on to learn how the enterprise-grade database combines the best of relational database structure and non-relational database scale with -- coming soon -- synchronous replication across regions and continents with a 99.999% (five nines) availability SLA.]

Building our infrastructure FirebaseApp Engine flexible environmentGoogle Cloud EndpointsCloud Identity and Access Management Database decisions Cloud Spanner pro tips

The first connection to Cloud Spanner takes a long time to initialize, which makes it difficult to expose an API through Cloud Functions. Instead, we used App Engine flexible environment to build our microservices API for a serverless approach that has very good performance. We use Cloud Functions for simple asynchronous scripts for background tasks that do not require an immediate answer to the client (e.g., sending an iOS notification given the user parameters) that we trigger via Cloud Pub/Sub.

Cloud Spanner allows us to change a schema in production without downtime. We always use a NOT NULL constraint, because we generally think that using NULL leads to more errors in application code. We always use a default value when we create an entity through our APIs and we use Cloud Dataflow to set values when we change a schema (e.g., adding a field to an entity).

With microservices, it’s generally a good practice to make sure every service has its own database to ensure data isolation between the different services. However, we adopted a slightly different strategy to optimize our use of Cloud Spanner. We have an instance on which there are three databases -- one for production, one for staging and one for testing our continuous integration (CI) pipeline. Each service has one or more interleaved tables that are isolated from others services’ tables (we do not use foreign-keys between tables from different services). This way our microservices data are not tightly “coupled”.

We created an internal query service that performs read-only queries to Cloud Spanner to generate a dashboard or do complex queries for analytics. It is the only service where we allow joins between tables across services.

We take advantage of Cloud Spanner’s scalability, and thus don’t delete any data that could one day be useful and/or profitable.

We store all of our business logs on Cloud Spanner, for example connection attempts to the application. We append the ‘-Logs’ suffix to them.

When possible, we always create an interleave.

It’s saved us weeks, if not months, of coding.

We feel we can rely on it since it’s been battle-tested by Google.

We can focus on building a disruptive financial services product for freelancers and SMBs.

Shine will launch in France this fall, and later throughout Europe. We have our sights set on the United States in the future too. To learn more about Shine, or talk about GCP or Cloud Spanner, feel free to reach out to us on Twitter.

Announcing Cloud IoT Core public beta

Wednesday, September 27, 2017

By Indranil Chakraborty, Product Manager, Google CloudGoogle Cloud IoT CoreCloud IoT CoreGoogle Cloud IoT solutionGoogle Cloud Pub/SubGoogle Cloud DataflowGoogle Cloud BigtableGoogle BigQueryGoogle Cloud Machine Learning Engine Key new features Bring your own certificate Connect existing devices with HTTP Logical device representation

Our customers share feedback “Our devices are heavily used and constantly send us a huge volume of data. By connecting these devices to Cloud IoT Core, we have a secure and reliable way to not only ingest that data but then also use it to gain valuable insights. We know exactly how our systems are performing and can push updates to devices to ensure we deliver the best products and services as cost effectively as possible.” John Heard, Group CTO, Smart Parking Limited .
“Our disruptive approach to automated embedded artificial intelligence is ideally suited for deployment using Google Cloud IoT Core. This integration enables our predictive models to not only run inside Google Cloud Platform but also inside the objects themselves, whether they are connected or not, with a single point of control and a unified management console. We are proud to have been selected by Google to help extend the value of AI in their IoT ecosystem.” Benoit Gourdon, CEO, Tellmeplus Partner ecosystem procure kits from our partners

Allwinner Technology

Arm

Intel

Marvell

Microchip

Mongoose OS

NXP

Realtek

Sierra Wireless

SOTEC

Pricing

this quick-start tutorialyour feedback

Now live: Online practice exam for Cloud Architect certification

Wednesday, September 27, 2017

By Carol Martin, Community Marketing ManagerPractice, practice, practice. practice examCloud Architect

practice exam

Extending per second billing in Google Cloud

Tuesday, September 26, 2017

By Paul Nash, Group Product Manager, Compute Engine
effective todaysustained use discountsPreemptible VMscustom machine typescommitted use discountssign up today and get $300 in free credits

Java 8 on App Engine standard environment is now generally available

Tuesday, September 26, 2017

By Amir Rouzrokh, Product ManagerannouncedJava 8 on App Engine standard environmentApp Engine Service Level Agreement (SLA)limited Java classesthread executionGoogle Cloud PlatformJetty 9gRPCGoogle Cloud Java Library supportSpring BootKotlin "The new Java 8 runtime brings performance enhancements to our application, leading to cost savings. Running on Java 8 also means increased developer happiness and efficiency, thanks to the removal of the class white list, and to the new features the language provides. Last but not least, upgrading from the Java 7 to the Java 8 runtime was a breeze." — Jerome Mouton, Co-founder and CTO, SnapEngagejava8the migration process heretraffic splittingApp Engine APIsMavenGradleIntelliJEclipseGoogle Cloud Java Librariesissue trackerOpenJDK 9

Committed use discounts for Google Compute Engine now generally available

Friday, September 22, 2017

By Manish Dalwadi, Product Manager, Compute EngineSustained use discountscommitted use discountsGoogle Compute Engine Simple and flexible —

"Our fleet is constantly changing with the evolving needs of our students and teachers. Even as we rapidly change instance types and Compute Engine zones, committed use discounts automatically apply to our aggregate usage, making it simple and straightforward to optimize our costs. The results speak for themselves: 60% of our total usage is now covered by committed use discounts, saving us thousands of dollars every month. Google really got the model right." — Peter Bakkum, Platform Lead, Quizlet
No hidden costs

"We see great financial benefits by using committed use discounts for predictable workloads. With committed use discounts, there are no upfront costs, unlike other platforms we have used. It’s also possible to change machine types as committed use discounts work on both vCPU and memory. We have been very happy with committed use discounts." — Gizem Terzi Türkoğlu, Project Coordinator, MetGlobal documentationpricing pagepricing calculatorclick here

Announcing Stackdriver Debugger for Node.js

Friday, September 22, 2017

By Justin Beckwith, Product Manager, Google Cloud PlatformStackdriver Error ReportingStackdriver Debugger

Stackdriver Debugger for Node.jsopen sourcenpm
Setting up Stackdriver Debugger for Node.js$ npm install --save @google-cloud/debug-agentrequire('@google-cloud/debug-agent') .start({ allowExpressions: true });

Using Logpoints Stackdriver Debugger Logpoints

full setup guide@googlecloudrequest an invite#nodejs

Introducing faster NVIDIA GPUs for Google Compute Engine

Thursday, September 21, 2017

By Chris Kleban and Ari Liberman, Product Managers for Google Compute EngineGoogle Cloud PlatformNVIDIAGoogle Compute Enginesustained use discountsgeophysical data processingPascal GPU architecture1

Flexibility: Google’s custom VM shapes and incremental Cloud GPUs provide the ultimate amount of flexibility. Customize the CPU, memory, disk and GPU configuration to best match your needs.

Fast performance: Cloud GPUs are offered in passthrough mode to provide bare-metal performance. Attach up to 4 P100 or 8 K80 per VM (we offer up to 4 K80 boards, that come with 2 GPUs per board). For those looking for higher disk performance, optionally attach up to 3TB of Local SSD to any GPU VM.

Low cost: With Cloud GPUs you get the same per-minute billing and Sustained Use Discounts that you do for the rest of GCP's resources. Pay only for what you need!

Cloud integration: Cloud GPUs are available at all levels of the stack. For infrastructure, Compute Engine and Container Engine (supported on alpha clusters only) allow you to run your GPU workloads with either VMs or containers. For machine learning, Cloud Machine Learning can be optionally configured to utilize GPUs in order to reduce the time it takes to train your models at scale with TensorFlow.

sustained use discounts

Cloud GPUs Regions Availability - Number of Zones

Speed up machine learning workloads launching GPUsShazam “For certain tasks, [NVIDIA] GPUs are a cost-effective and high-performance alternative to traditional CPUs. They work great with Shazam’s core music recognition workload, in which we match snippets of user-recorded audio fingerprints against our catalog of over 40 million songs. We do that by taking the audio signatures of each and every song, compiling them into a custom database format and loading them into GPU memory. Whenever a user Shazams a song, our algorithm uses GPUs to search that database until it finds a match. This happens successfully over 20 million times per day.” — Ben Belchak, Head of Site Reliability Engineering, ShazamGPU siteget started 1 The 10x performance boost compares 1 P100 GPU versus 1 K80 GPU (½ of a K80 board) for machine learning inference workloads that benefits from the P100 FP16 precision. Performance will vary by workload. Download this datasheet for more information.

Announcing IPv6 global load balancing GA

Wednesday, September 20, 2017

By Prajakta Joshi, Product Manager, Cloud NetworkingCloud Load BalancingIPv6 global load balancingHTTP(S) Load Balancing, SSL proxyTCP proxymultiple regionshomedepot.comGoogle Cloud Platform "On the front-end, we use the Layer 7 load balancer with a single global IP that intelligently routes customer requests to the closest location. Global load balancing will allow us to easily add another region in the future without any DNS record changes, or for that matter, doing anything besides adding VMs in the right location." — Ravi Yeddula, Senior Director Platform Architecture and Application Development, The Home Depot IPv6 support unlocks new capabilities

Single Anycast IPv6 VIP for multi-region deployment: Now, you only need one Load Balancer IPv6 VIP for application instances running across multiple regions. This means that your DNS server has a single AAAA record and that you don’t need to load-balance among multiple IPv6 VIPs. Caching of AAAA records by clients is not an issue since there's only one IPv6 VIP to cache. User requests to IPv6 VIP are automatically load balanced to the closest healthy instance with available capacity.

Support for a variety of traffic types: You can load balance HTTP, HTTPS, HTTP/2, TCP and TLS (non-HTTP) IPv6 client traffic.

Cross-region overflow with a single IPv6 Load Balancer VIP: If instances in one region are out of resources, the IPv6 global load balancer automatically directs requests from users closest to this region to another region with available resources. Once the closest region has available resources, global load balancing reverts back to serving user requests via instances in this region.

Cross-region failover with single IPv6 Load Balancer VIP: If the region with instances closest to the user experiences a failure, IPv6 global load balancing automatically directs traffic to another region with healthy instances.

Dual-stack applications: To serve both IPv6 and IPv4 clients, create two load balancer IPs — one with an IPv6 VIP and the other with an IPv4 VIP — and associate both VIPs with the same IPv4 application instances. IPv4 clients connect to the IPv4 Load Balancer VIP while IPv6 clients connect to IPv6 Load Balancer VIP. These clients are then automatically load balanced to the closest healthy instance with available capacity. We provide IPv6 VIPs (forwarding rules) without charge, so you pay for only the IPv4 ones.

(click to enlarge)

A global, scalable, resilient foundation

Software-defined, globally distributed load balancing: Global load balancing is delivered via software-defined, globally distributed systems. This means that you won’t hit performance bottlenecks with the load balancer and it can handle 1,000,000+ queries per second seamlessly.

Reduced latency through edge-based architecture: Global load balancing is delivered at the edge of Google's global network from 80+ points of presence (POPs) across the globe. User connections terminate at the POP closest to them and travel over Google's global network to the load-balanced instance in Google Cloud.

(click to enlarge)

Seamless autoscaling: Global load balancing scales application instances up or down automatically based on traffic — no pre-warming of instances required.

Take IPv6 global load balancing for a spin sneak preview of IPv6 global load balancing

v6.gcpnetworking.com is served by IPv4 application instances in multiple Google Cloud regions across the globe.

A single anycast IPv6 Load Balancer IP, 2600:1901:0:ab8:: fronts the IPv4 application instances across regions

When you connect using an IPv6 address to this website, IPv6 global load balancing directs you to a healthy Google Cloud instance that's closest to you and has available capacity.

The website is programmed to display your IPv6 address, the Load Balancer IPv6 VIP and information about the instance serving your request.

v6.gcpnetworking.com will only work with IPv6 clients. You can test drive gcpnetworking.com instead if you want to test with both IPv4 and IPv6 clients.

v6.gcpnetworking.comIPv6 global load balancingyour feedback