Kategorie: Google Cloud Platform

The modern web architecture jigsaw puzzle, made easy for you

Delivering web-based software is no longer as simple as ssh’ing into a LAMP server and vi’ing a php file. For good reasons, many of us have evolved practices and adopted technologies to address growing complexities and modern needs. Recently I put together a jigsaw puzzle of various technologies and practices so that I could deploy a globally distributed, scale-on-demand, edge-cached, webapp while taking advantage of container-based portability, infrastructure automation, and Continuous Integration / Continuous Delivery.The major pieces of the puzzle include: The Java Virtual Machine (JVM), Scala, sbt, Docker, GraalVM, Cloud Native Buildpacks, bash, git, GitHub Actions, Google Cloud Run, Google Cloud Build, Google Cloud CDN, Google Container Registry, and Google Domains. That is a lot of pieces!  Let’s first look at the use case that I was solving for.JavaDocs globally distributed & scale-on-demandLibraries in the JVM ecosystem (created with Java, Kotlin, Scala, etc) are typically published to a repository called Maven Central. It currently has over 6 million artifacts (a version of some library). When a library author publishes their library they typically include an artifact that contains versioned documentation (i.e. JavaDoc). These artifacts are basically ZIP files containing some generated HTML. When you use a library typically you reference its JavaDoc either in your IDE or on a webpage where it has been published.As a fun experiment I created a website that pulls JavaDocs out of Maven Central and displays them on a webpage. If you are familiar with Java libraries and can think of one, check out my website:https://javadocs.dev/As an example, check out the gRPC Kotlin stub JavaDocs:https://javadocs.dev/io.grpc/grpc-kotlin-stub/latestThat site should have loaded super fast for you, no matter where you are, because I’ve put together the puzzle of creating a scale-on-demand webapp that is globally distributed with great edge caching. Here’s what the runtime architecture looks like:1. Get latest JavaDocs for io.grpc:grpc-kotlin-stubjavadocs.dev/io.grpc/grpc-kotlin-stub/latest2. Get index.html for JavaDoc io.grpc:grpc-kotlin-stub:1.0.0javadocs.dev/io.grpc/grpc-kotlin-stub/1.0.0/index.htmlBest of all, the entire system is continuously delivered on merge to main via a few lines of Cloud Build configuration. As a spoiler, here is all the build config you need to have the same sort of globally distributed, scale-on-demand, edge-cached, webapp:To make things that easy and to make the app start super fast, I had to go on a bit of a journey putting together many different pieces. Let’s walk through everything.Super-fast startup without sacrificing developer experienceThe “JavaDoc Central” webapp is a proxy for Maven Central metadata and artifacts. It needs to query metadata from the repository like translating a version of “latest” to the actual latest version. When a user requests the JavaDoc for a given artifact it needs to pull that associated JavaDoc from Maven Central, extract it, and then serve the content.Traditionally webapp hosting relied on over-provisioning so that when a request arrives the server is ready to handle it. Scale-on-demand takes a more efficient approach where underlying resources are dynamically allocated as requests come in but are also automatically deallocated when the number of requests decreases. This is also called auto-scaling or serverless. The nice thing about scale-on-demand is that there aren’t wasted / underutilized servers. But a challenge with this approach is that applications need to startup super fast because when the demand (number of requests) exceeds the available supply (underlying servers), a new server needs to be started so the excess demand can then be handled by a freshly started server. This is called a “cold-start” and has different impacts depending on many variables: programming platform, size of application, necessity for cache hydration, connection pooling, etc.Cold-starts happen any time the demand exceeds the supply, not just when scaling up from zero servers.An easy way to deal with some cold-start issues is to use programming platforms that don’t have significant startup overhead. JVM-based applications typically take at least a few seconds to startup because the JVM has startup overhead, JAR loading takes time, classpath scanning for dependency injection can be slow, etc. For this reason technologies like Node.js, Go, and Rust have been popular with scale-on-demand approaches.Yet, I like working on the JVM for a variety of reasons including: great library & tooling ecosystem and modern high-level programming languages (Kotlin & Scala). I’m incredibly productive on the JVM and I don’t want to throw away that productivity just to better support scale-on-demand. For more details, read my blog: The Modern Java Platform – 2021 EditionLuckily there is a way to have my cake and eat it too!  GraalVM Native Image takes JVM-based applications and instead of running them on the JVM, it Ahead-Of-Time (AOT) compiles them into native applications. But that process takes time (minutes, not seconds) and I wouldn’t want to wait for that to happen as part of my development cycle. The good news is that I can run JVM-based applications on the JVM as well as native images. This is exactly what I do with the JavaDoc Central code. Here is what my development workflow looks like:To create a native image with GraalVM I used a build tool plugin. Since I’m using Scala and the sbt build tool, I used the sbt-native-packager plugin but there are similar plugins for Maven and Gradle. This enables my Continuous Delivery system to run a command to create an AOT native executable from my JVM-based application:./sbt graalvm-native-image:packageBinGraalVM Native Image optionally allows native images to be statically linked so they don’t even need an operating system to run. The resulting container image for my entire statically linked JavaDoc webapp is only 15MB and starts up in well under a second. Perfect for on-demand scaling!Multi-region deployment automationWhen I first deployed the javadocs.dev site I manually created a service on Cloud Run that runs my 15MB container image but Cloud Run services are region-based so latency to them differ depending on where the user is (turns out the speed of light is fairly slow for round-the-globe TCP traffic). Cloud Run is available in all 24 Google Cloud regions but I didn’t want to manually create all those services and the related networking infrastructure to handle routing. There is a great Cloud Run doc called “Serving traffic from multiple regions” that walks through all the steps to create a Google Cloud Load Balancer in front of n-number of Cloud Run services. Yet, I wanted to automate all that so I embarked on a journey that further complicated my puzzle but resulted in a nice tool that I use to automate global deployments, network configurations, and global load balancing.There are a number of different ways to automate infrastructure setup, including Terraform support for Google Cloud. But I just wanted a container image that’d run some gcloud commands for me. Writing those commands is pretty straightforward but I also wanted to containerize them so they’d be easily reusable in automated deployments.Typically, to containerize stuff like this, a Dockerfile is used to define the steps needed to go from source to the thing that will be runnable in the container. But Dockerfiles are only reusable with copy & paste resulting in security and maintenance costs that are not evident initially. So I decided to build a Cloud Native Buildpack for gcloud scripts that anyone could reuse to create containers for gcloud automations. Buildpacks provide a way to reuse the logic for how source gets turned into runnable stuff in a container.After an hour of learning how to create a Buildpack, the gcloud-buildpack was ready!  There are only a couple pieces which you don’t really need to know about since Buildpacks abstracts away the process of turning source into a container image, but let’s go into them so you can understand what is under-the-covers.Buildpack run imageBuildpacks add docker layers onto a “run image” so a Buildpack needs one of those. My gcloud-buildpack needs a run image that has the gcloud command in it. So I just created a new run image based on the gcloud base image and with two necessary labels (Docker metadata) for the Buildpacks:I also needed to setup automation so the run image would automatically be created and stored on a container registry, and any changes would update the container image. I decided to use GitHub Actions to run the build and the GitHub Container Registry to store the container image. Here is the Action’s YAML:Voila! The run image is available and continuously deployed:ghcr.io/jamesward/gcloud-buildpack-run:latestgcloud BuildpackBuildpacks participate in the Cloud Native Buildpack lifecycle and must implement at least two phases: detect & build. Buildpacks can be combined together so you can run something like:pack build –builder gcr.io/buildpacks/builder:v1 fooAnd all of the Buildpacks in the Builder Image will be asked if they know how to build the specified thing. In the case of the Google Cloud Buildpacks they know how to build Java, Go, Node.js, Python, and .NET applications. For my gcloud Buildpack I don’t have plans to add it to a Builder Image so I decided to have my detection always result in a positive result (meaning the buildpack will run no matter what). To do that my detect script just exits without an error. Note: You can create Buildpacks with any technology since they run inside the Builder Image in docker; I just decided to write mine in Bash because reasons.The next phase for my gcloud Buildpack is to “build” the source but since the Buildpack is just taking shell scripts and adding them to my run image, all that needs to happen is to copy the scripts to the right place and tell the Buildpack lifecycle that they are executables / launchable processes. Check out the build code.Since Buildpacks can be used via container images, my gcloud Buildpack needs to be built and published to a container registry. Again I used GitHub Actions:From the user’s perspective, to use the gcloud Buildpack all they have to do is:Create a project containing a .sh fileBuild your project with pack:Now with a gcloud Buildpack in place I’m ready to create a container image that makes it easy to deploy a globally load-balanced service on Cloud Run!Easy Cloud RunI created a bash script that automates the documented steps to setup a multiregion Cloud Run app so that they can all be done as part of a CI/CD pipeline. If you’re interested, check out the source. Using the new gcloud-buildpack I was able to package the command into a container image via GitHub Actions:Now anyone can use the ghcr.io/jamesward/easycloudrun container image with six environment variables, to automate the global load balancer setup and multi-region deployment. When this runs for the javadoccentral repo it looks like this:All of the networking and load balancer configuration is automatically created (if it doesn’t exist) and the Cloud Run services are deployed with the –ingress=internal-and-cloud-load-balancing option so that only the load balancer can talk to them. Even the http to https redirect is created on the load balancer. Here is what the load balancer and network endpoint groups look like in the Google Cloud Console:Setting up a serverless, globally distributed application that is backed by 24 Google Cloud regions all happens in about 1 minute as part of my CI/CD pipeline.Cloud Build CI/CDLet’s bring this all together into a pipeline that tests the javadocs.dev application, creates the GraalVM Native Image container, and does the multi-region deployment. I used Cloud Build since it has GitHub integration and uses service accounts to control the permissions of the build (making it easy to enable Cloud Run deployment, network config setup, etc). The Cloud Build definition (source on GitHub):Step 1 runs the application’s tests. Step 2 builds the application using GraalVM Native Image. Step 3 pushes the container images to the Google Cloud Container Registry. And finally Step 4 does the load balancer / network setup and deploys the application to all 24 regions. Note that I use a large machine for the build since GraalVM Native Image uses a lot of resources. The only custom value in that CI/CD pipeline is the DOMAINS which are needed to setup the load balancer. Everything else is boilerplate.The puzzle comes together!So that was quite the jigsaw puzzle with many pieces!  Now that I’ve glued all the pieces together it should be pretty straightforward for you to create your own serverless, globally distributed application on Google Cloud and deploy with easycloudrun. Or maybe you want to use the gcloud Buildpack to create your own automations. Either way, let me know how I can help!Related ArticleIntroducing Cloud Run Button: Click-to-deploy your git repos to Google CloudAdding the Cloud Run button to your github source code repositories lets anyone deploy their application to Google Cloud.Read Article
Quelle: Google Cloud Platform

6 database trends to watch

In a data-driven, global, always-on world, databases are the engines that let businesses innovate and transform. As databases get more sophisticated and more organizations look for managed database services to handle infrastructure needs, there are a few key trends we’re seeing. Here’s what to watch.We’re looking forward to what’s next in databases. You can’t predict the future, but you can be prepared for it—join us at our Data Cloud Summit to learn and connect, on May 26, 2021.Related ArticleGoogle charts the course for a modern data cloudWhy Google Cloud is leading the operational database management systems (DBMS) market with an open, multi-cloud, enterprise-ready vision.Read Article
Quelle: Google Cloud Platform

Using TFX inference with Dataflow for large scale ML inference patterns

In part I of this blog series we discussed best practices and patterns for efficiently deploying a machine learning model for inference with Google Cloud Dataflow. Amongst other techniques, it showed efficient batching of the inputs and the use of shared.py to make efficient use of a model.In this post, we walk through the use of the RunInference API from tfx-bsl, a utility transform from TensorFlow Extended (TFX), which abstracts us away from manually implementing the patterns described in part I. You can use RunInference to simplify your pipelines and reduce technical debt when building production inference pipelines in batch or stream mode. The following four patterns are covered:Using RunInference to make ML prediction calls.Post-processing  RunInference results. Making predictions is often the first part of a multistep flow, in the business process. Here we will process the results into a form that can be used downstream.Attaching a key.Along with the data that is passed to the model, there is often a need for an identifier — for example, an IOT device ID or a customer identifier — that is used later in the process even if it’s not used by the model itself. We show how this can be accomplished.Inference with multiple models in the same pipeline. Often you may need to run multiple models within the same pipeline, be it in parallel or as a sequence of predict – process – predict calls. We walk through a simple example.Creating a simple modelIn order to illustrate these patterns, we’ll use a simple toy model that will let us concentrate on the data engineering needed for the input and output of the pipeline. This model will be trained to approximate multiplication by the number 5.Please note the following code snippets can be run as cells within a notebook environment. Step 1 – Set up libraries and imports%pip install tfx_bsl==0.29.0 –quiet Step 2 – Create the example data In this step we create a small dataset that includes a range of values from 0 to 99 and labels that correspond to each value multiplied by 5.Step 3 – Create a simple model, compile, and fit it Let’s teach the model about multiplication by 5.model.fit(x, y, epochs=2000)Next, check how well the model performs using some test data.From the results below it looks like this simple model has learned its 5 times table close enough for our needs!Step 4 – Convert the input to tf.exampleIn the model we just built, we made use of a simple list to generate the data and pass it to the model. In this next step we make the model more robust by using tf.example objects in the model training. tf.example is a serializable dictionary (or mapping) from names to tensors, which ensures the model can still function even when new features are added to the base examples. Making use of tf.example also brings with it the benefit of having the data be portable across models in an efficient, serialized format. To use tf.example for this example, we first need to create a helper class, ExampleProcessor, that is used to serialize the data points.Using the ExampleProcess class, the in-memory list can now be moved to disk.With the new examples stored in TFRecord files on disk, we can use the Dataset API to prepare the data so it is ready for consumption by the model.With the feature spec in place, we can train the model as before. Note that these steps would be done automatically for us if we had built the model using a TFX pipeline, rather than hand-crafting the model as we did here. Step 5 – Save the modelNow that we have a model, we need to save it for use with the RunInference transform. RunInference accepts TensorFlow saved model pb files as part of its configuration. The saved model file must be stored in a location that can be accessed by the RunInference transform. In a notebook this can be the local file system; however, to run the pipeline on Dataflow, the file will need to be accessible by all the workers, so here we use a GCP bucket. Note that the gs:// schema is directly supported by the tf.keras.models.save_model api.tf.keras.models.save_model(model, save_model_dir_multiply)During development it’s useful to be able to inspect the contents of the saved model file. For this, we use the saved_model_cli that comes with TensorFlow. You can run this command from a cell: !saved_model_cli show –dir {save_model_dir_multiply} –allAbbreviated output from the saved model file is shown below. Note the signature def ‘serving_default’, which accepts a tensor of float type. We will change this to accept another type in the next section.RunInference will pass a serialized tf.example to the model rather than a tensor of float type as seen in the current signature. To accomplish this we have one more step to prepare the model: creation of a specific signature. Signatures are a powerful feature as they enable us to control how calling programs interact with the model. From the TensorFlow documentation:”The optional signatures argument controls which methods in obj will be available to programs which consume SavedModels, for example, serving APIs. Python functions may be decorated with @tf.function(input_signature=…) and passed as signatures directly, or lazily with a call to get_concrete_function on the method decorated with @tf.function.”In our case, the following code will create a signature that accepts a tf.stringdata type with a name of examples. This signature is then saved with the model, which replaces the previous saved model.If you run the saved_model_cli command again, you will see that the input signature has changed to DT_STRING. Pattern 1: RunInference for predictionsStep 1 – Use RunInference within the pipelineNow that the model is ready, the RunInference transform can be plugged into an Apache Beam pipeline. The pipeline below uses TFXIO  TFExampleRecord, which it converts to a transform via RawRecordBeamSource(). The saved model location and signature are passed to the RunInference API as a SavedModelSpec configuration object.Note: You can perform two types of inference using RunInference: In-process inference from a SavedModel instance. Used when the saved_model_spec field is set in inference_spec_type.  Remote inference by using a service endpoint. Used when the ai_platform_prediction_model_spec field is set in inference_spec_type.Below is a snippet of the output. The values here are a little difficult to interpret as they are in their raw unprocessed format. In the next section the raw results are post-processed.Pattern 2: Post-processing RunInference resultsThe RunInference API returns a PredictionLog object, which contains the serialized input and the output from the call to the model. Having access to both the input and output enables you to create a simple tuple during post-processing for use downstream in the pipeline. Also worthy of note is that RunInference will consider the amenable-to-batching capability of the model (and does batch inference for performance purposes) transparently for you. The PredictionProcessor beam.DoFn takes the output of RunInference and produces formatted text with the questions and answers as output. Of course in a production system, the output would more normally be a Tuple[input, output], or simply the output depending on the use case.Now the output contains both the original input and the model’s output values. Pattern 3: Attaching a keyOne useful pattern is the ability to pass information, often a unique identifier, with the input to the model and have access to this identifier from the output. For example, in an IOT use case you could associate a device id with the input data being passed into the model. Often this type of key is not useful for the model itself and thus should not be passed into the first layer.RunInference takes care of this for us, by accepting a Tuple[key, value] and outputting Tuple[key, PredictLog]Step 1 – Create a source with attached keySince we need a key with the data that we are sending in for prediction, in this step we create a table in BigQuery, which has two columns: One holds the key and the second holds the test value.Step 2 – Modify post processor and pipelineIn this step we:Modify the pipeline to read from the new BigQuery source tableAdd a map transform, which converts a table row into a Tuple[ bytes, Example]Modify the post inference processor to output results along with the keyPattern 4: Inference with multiple models in the same pipelineIn part I of the series, the “join results from multiple models” pattern covered the various branching techniques in Apache Beam that make it possible to run data through multiple models. Those techniques are applicable to RunInference API, which can easily be used by multiple branches within a pipeline, with the same or different models. This is similar in function to cascade ensembling, although here the data flows through multiple models in a single Apache Beam DAG.Inference with multiple models in parallelIn this example, the same data is run through two different models: the one that we’ve been using to multiply by 5 and a new model, which will learn to multiply by 10.Now that we have two models, we apply them to our source data. Inference with multiple models in sequence In a sequential pattern, data is sent to one or more models in sequence, with the output from each model chaining to the next model.Here are the steps: Read the data from BigQueryMap the dataRunInference with multiply by 5 modelProcess the resultsRunInference with multiply by 10 modelProcess the resultsRunning the pipeline on DataflowUntil now the pipeline has been run locally, using the direct runner, which is implicitly used when running a pipeline with the default configuration. The same examples can be run using the production Dataflow runner by passing in configuration parameters including –runner. Details and an example can be found here.Here is an example of the multimodel pipeline graph running on the Dataflow service:With the Dataflow runner you also get access to pipeline monitoring as well as metrics that have been output from the RunInference transform. The following table shows some of these metrics from a much larger list available from the library.ConclusionIn this blog, part II of our series, we explored the use of the tfx-bsl RunInference within some common scenarios, from standard inference, to post processing and the use of RunInference API in multiple locations in the pipeline.To learn more, review the Dataflow and TFX documentation, you can also try out TFX with Google Cloud AI platform pipelines..  AcknowledgementsNone of this would be possible without the hard work of many folks across both the Dataflow  TFX and TF teams. From the TFX and TF team we would especially like to thank Konstantinos Katsiapis, Zohar Yahav, Vilobh Meshram, Jiayi Zhao, Zhitao Li, and Robert Crowe. From the Dataflow team I would like to thank Ahmet Altay for his support and input throughout.Related ArticleMachine learning patterns with Apache Beam and the Dataflow Runner, part IAs more people use ML inference in Dataflow pipelines to extract insights from data, we’ve seen some common patterns emerge. In this post…Read Article
Quelle: Google Cloud Platform

Introducing Open Saves: Open-source cloud-native storage for games

Many of today’s games are rich, immersive worlds that engage the audience in ways that make a gamer a part of a continuing storyline. To create these persistent experiences, numerous storage technologies are required to ensure game data can scale to the standards of gamers’ demands. Not only do game developers need to store different types of data—such as saves, inventory, patches, replays, and more—but they also must keep the storage system high-performing, available, scalable, and cost-effective.Enter Open Saves, a brand-new, purpose-built single interface for multiple storage back ends that’s powered by Google Cloud and developed in partnership with 2K. Now, development teams can store game data without having to make the technical decisions on which storage solution to use, whether that’s Cloud Storage, Memorystore, or Firestore. “Open Saves demonstrates our commitment to partnering with top developers on gaming solutions that require a combination of deep industry expertise and Google scale,” said Joe Garfola, Vice President of IT and Security at 2K. “We look forward to continued collaboration with Google Cloud.”Game development teams can save game data against Open Saves without having to worry about the optimal back-end storage solution, while operations teams can focus on needed scalability and storage options. Here’s how it looks in practice:With Open Saves, game developers can run a cloud-native game storage system that is:Simple: Open Saves provides a unified, well-defined gRPC endpoint for all operations for metadata, structured, and unstructured objects.Fast: With a built-in caching system, Open Saves optimizes data placements based on access frequency and data size, all to achieve both low latency for smaller binary objects and high throughput for big objects.Scalable: The Open Saves API server can run on either Google Kubernetes Engine or Cloud Run. Both platforms can scale out to handle hundreds of thousands of requests per second. Open Saves also stores data in Firestore and Cloud Storage, and can handle hundreds of gigabytes of data and up to millions of requests per second.Open Saves is designed with extensibility in mind, and can be integrated into any game—whether mobile or console, multiplayer or single player—running on any infrastructure, from on-prem to cloud or a hybrid. The server is written in Go, but you can use many programming languages and connect from client or server since the API is defined in gRPC.Writing to and reading from Open Saves is as simple as the following code:We are actively developing Open Saves in partnership with 2K Games, and would love for you to come join us on GitHub. There are a few ways to get involved:Install and deploy your Open Saves serviceCheck out the API referenceRead the development guide and start contributingJoin the open-saves-discuss mailing listRelated ArticleOpen Match: Flexible and extensible matchmaking for gamesGoogle Cloud and Unity are jointly announcing the availability of Open Match, an open source matchmaking solution offering game creators …Read Article
Quelle: Google Cloud Platform

How Anthos supports your multicloud needs from day one

Most enterprises that run in the cloud have already spent a significant amount of effort automating, operationalizing, and securing their environment. Many have spent years investing in a single cloud provider. Yet today, the ability to run workloads on multiple cloud providers is becoming increasingly important.Why? There are multiple reasons. Some organizations want application teams to be able to take advantage of the best service for a given application. Others have acquired a company which runs on another cloud. And still others want the ability to spread out risk across multiple vendors. At the same time, there are also challenges associated with multicloud. Having multiple cloud providers means you must accept having different APIs, operational tools, security standards, and ways of working. Resource sprawl becomes significantly worse when you have multiple cloud platforms. Without a single place to see all of your resources, inventorying, monitoring, and keeping these systems up to date can become difficult. Creating secure environments within multiple cloud platforms is another challenge. With each platform having different security capabilities, identity systems, and risks. Supporting an additional cloud platform often means doubling your security efforts.Finally, the biggest challenge with multicloud can be the inconsistency between platforms. In an ideal world, application teams would not need to worry about platform-specific details. They would be able to build their application and deploy it to any cloud platform, or move it between platforms, even if platform-specific details such as storage, load balancing, networking, workload identity, and security make each platform quite different.Is multicloud worth it? Yes.For many organizations, multicloud is only worth it if they can find a smart way to address these challenges. For a growing number of companies, the solution is Anthos.Rather than relying on your application or cloud infrastructure teams to build tools to operate across multiple platforms, Anthos provides these capabilities out-of-the-box. Anthos provides the core capabilities for deploying and operating infrastructure and services across Google Cloud, AWS, and soon in Azure. For infrastructure teams, Anthos provides a single way to provision, view, and manage distributed infrastructure, characterized by:A simple API-driven deployment mechanismReliable one-step cluster upgrades that updates the Google-managed Kubernetes distribution, the server OS, and all of the supporting system pods and servicesA single web console for viewing cluster state, nodes, attached volumesA powerful configuration and policy management system which can be used to enforce security policies, RBAC rules, network policies, and any other Kubernetes objectsA fully managed logging system with a powerful search capability, log-based metrics, and custom retention rulesSoftware supply-chain security to ensure only trusted code is running in your environmentHybrid identity service compatible with Active Directory, AWS IAM, and other OIDC-based identity providersAnd for application teams, Anthos offers a consistent deployment target regardless of which cloud you’re targeting, characterized by:A familiar Kubernetes API that provides a consistent way of provisioning storage, load balancers, and ingress rulesA single web console for deploying, updating, and monitoring workloads and servicesAn open-source, serverless application framework A consistent way to securely access cloud-managed services that your app depends onA single Kubernetes API endpoint for connecting to multiple clusters across multiple platforms, even without direct network connectivity (especially great for enabling your CI/CD pipeline to run anywhere)A fully-managed logging system with strong support for multi-tenancy so you only see logs for your applicationThe option to auto-discover and collect custom application metrics, dashboarding, alerting, and incident managementPlays nice with othersThere are a lot of Kubernetes clusters already deployed out in the wild. Every cluster should not need to be completely replaced to build a multicloud environment. The promise of Kubernetes is that it provides a single API and common set of objects. Because of this, Anthos provides a subset of capabilities to existing Kubernetes clusters, and existing Amazon EKS, Microsoft AKS, or Red Hat OpenShift clusters can be attached to the Anthos management plane. These attached clusters can take advantage of the same operational management capabilities of Anthos-native clusters, including:The web console for deploying, updating, and monitoring workloads and servicesPolicy and configuration managementLogging, monitoring, dashboarding, and alertingThe single Kubernetes API end-point which is always available so you don’t need to worry about network connectivity Anthos-attached clusters provide an easy onboarding path that allows users to connect existing clusters to Google Cloud in minutes and start managing them through a single pane of glass. The connection does not require special networking capabilities and is simple to set up. This allows users to use any Kubernetes cluster they have alongside their Google Kubernetes Engine (GKE) clusters.Of course, you still use native tools for EKS, AKS, and OpenShift for cluster creation, upgrades, and deletes; but once a cluster is attached to Anthos, you can manage the cluster just like any other Anthos cluster.Check out the recent blog post on Anthos 1.7 release. We announced new features for Anthos that our customers tell us will drive business agility and efficiency in the multicloud world. The Anthos Sample Deployment on Google Cloud today is a great place to start with an actual application. You can also deploy Anthos to your AWS account or try out attaching your existing clusters to Anthos.Related Article3 keys to multicloud success you’ll find in Anthos 1.7The new Anthos 1.7 lets you do a whole lot more than just run in multiple clouds.Read Article
Quelle: Google Cloud Platform

The evolution of Kubernetes networking with the GKE Gateway controller

Last week the Kubernetes community announced the Gateway API as an evolution of the Kubernetes networking APIs. Led by Google and a variety of contributors, the Gateway APIunifies networking under a core set of standard resources. Similar to how Ingress created an ecosystem of implementations, the Gateway API delivers unification, but on an even broader scope and based on lessons from Ingress and service mesh.Today we’re excited to announce the Preview release of the GKE Gateway controller, Google Cloud’s implementation of the Gateway API. Over a year in the making, the GKE Gateway controller manages internal and external HTTP/S load balancing for a GKE cluster or a fleet of GKE clusters. The Gateway API provides multi-tenant sharing of load balancer infrastructure with centralized admin policy and control. Thanks to the API’s expressiveness, it supports advanced functionality such as traffic shifting, traffic mirroring, header manipulation and more. Take the tour below to learn more!A tour of the GKE Gateway controllerThe first new resource you’ll encounter in the GKE Gateway controller is the GatewayClass. GatewayClasses provide a template that describes the capabilities of the class. In every GKE 1.20+ cluster you’ll see two pre-installed GatewayClasses. Go spin up a GKE 1.20+ cluster and check for them right now!These GatewayClasses correspond to the regional Internal (gke-l7-rilb) and global External (gke-l7-gxlb) HTTP(S) Load Balancers, which are orchestrated by the Gateway controller to provide container-native load balancing. Role-oriented designThe Gateway API is designed to be multi-tenant. It introduces two primary resources that create a separation of concerns between the platform owner and the service owner:Gateways represent the load balancer that is listening for traffic that it routes. You can have multiple Gateways, one per team or just a single Gateway that is shared among different teams.Routes are the protocol-specific routing configuration that are applied to these Gateways. GKE supports HTTPRoutes today, with TCPRoutes and UDPRoutes on the roadmap. One or more Routes can bind to a Gateway and together they define the routing configuration of your application.The following example (which you can deploy in this tutorial), shows how the cluster operator deploys a Gateway resource to be shared by different teams, even across different Namespaces. The owner of the Gateway can define domain ownership, TLS termination, and other policies in a centralized way without involving service owners. On the other hand, service owners can define routing rules and traffic management that are specific to their app, without having to coordinate with other teams or with the platform administrators. The relationship between Gateway and Route resources creates a formal separation of responsibilities that can be managed by standard Kubernetes RBAC.Advanced routing and traffic managementThe GKE Gateway controller introduces new routing and traffic management capabilities. The following HTTPRoute was deployed by the Store team in their Namespace. It matches traffic for foo.example.com/store and applies these traffic rules:90% of the client traffic goes to store-v110% of the client traffic goes to store-v2 to canary the next version of the storeAll of the client traffic is also copied and mirrored to store-v3 for scalability testing of the following version of the storeNative multi-cluster supportThe GKE Gateway controller is built with native multi-cluster support for both internal and external load balancing via its multi-cluster GatewayClasses. Multi-cluster Gateways load-balance client traffic across a fleet of GKE clusters. This targets various use cases including:Multi-cluster or multi-region redundancy and failoverLow latency serving through GKE clusters that have close proximity to clientsBlue-green traffic shifting between clusters (try this tutorial)Expansion to multiple clusters because of organizational or security constraintsOnce ingress is enabled in your Hub, the multi-cluster GatewayClasses (with `-mc`) will appear in your GKE cluster, ready to use across your fleet.The GKE Gateway controller is tightly integrated with multi-cluster Services so that GKE can provide both north-south and east-west multi-cluster load balancing. Multi-cluster Gateways leverage the service discovery of multi-cluster Services so that they have a full view of Pod backends. External multi-cluster Gateways provide internet load balancing andinternal multi-cluster Gateways provide internal, private load balancing. Whether your traffic flows are east-west, north-south, public, or private, GKE provides all the multi-cluster networking capabilities that you need right out of the box.The GKE Gateway controller is Google Cloud’s first implementation of the Gateway API. Thanks to a loosely coupled resource model, TCPRoutes, UDPRoutes, and TLSRoutes will also soon be added to the Gateway API specification, expanding its scope of capabilities. This is the beginning of a new chapter in Kubernetes Service networking and there is a long road ahead! Learn moreThere are many resources available to learn about the Gateway API and how to use the GKE Gateway controller. Check out one of these Learn K8s tutorials on Gateway API concepts:Introduction to the Gateway APIGateway API Concepts
Quelle: Google Cloud Platform