Category Archives: Google Cloud Platform Blog

Product updates, customer stories, and tips and tricks on Google Cloud Platform

Building reliable deployments with Spinnaker, Container Engine and Container Builder

By Vic Iglesias, Cloud Solutions Architect

Kubernetes has some amazing primitives to help you deploy your applications, which let Kubernetes handle the heavy lifting of rolling out containerized applications. With Container Engine you can have your Kubernetes clusters up in minutes ready for your applications to land on them.

But despite the ease of standing up this fine-tuned deployment engine, there are many things that need to happen before deployments can even start. And once they’ve kicked off, you’ll want to make sure that your deployments have completed safely and in a timely manner.

To fill these gaps, developers often look to tools like Container Builder and Spinnaker to create continuous delivery pipelines.



We recently created a solutions guide that shows you how to build out a continuous delivery pipeline from scratch using Container Builder and Spinnaker. Below is an example continuous delivery pipeline that validates your software, builds it, and then carefully rolls it out to your users:



First, your developers tag your software and push it to a Git repository. When the tagged commit lands in your repository, Container Builder detects the change and begins the process of building and testing your application. Once your tests have passed, an immutable Docker image of your application is tagged and pushed to Container Registry. Spinnaker picks it up from here by detecting that a new Docker image has been pushed to your registry and starting the deployment process.

Spinnaker’s pipeline stages allow you to create complex flows to roll out changes. The example here uses a canary deployment to roll out the software to a small percentage of users, and then runs a functional validation of your application. Once those functional checks are complete in the canary environment, Spinnaker pauses the deployment pipeline and waits for a manual approval before it rolls out the application to the rest of your users. Before approving it, you may want to inspect some key performance indicators, wait for traffic in your application to settle or manually validate the canary environment. Once you’re satisfied with the changes, you can approve the release and Spinnaker completes rolling out your software.

As you can imagine, this exact flow won’t work for everyone. Thankfully Spinnaker and Container Builder give you flexible and granular stages that allow you to automate your release process while mapping it to the needs of your organization.

Get started by checking out the Spinnaker solution. Or visit the documentation to learn more about Spinnaker’s pipeline stages.


Customizing Stackdriver Logs for Container Engine with Fluentd

By John La Barge, Cloud Solutions Architect

 Many Google Cloud Platform (GCP) users are now migrating production workloads to Container Engine, our managed Kubernetes environment.  Container Engine supports Stackdriver logging on GCP by default, which uses Fluentd under the hood to send your logs to Stackdriver. 


You may also want to fully customize your Container Engine cluster’s Stackdriver logs with additional logging filters. If that describes you, check out this tutorial where you’ll learn how you can configure Fluentd in Container Engine to apply additional logging filters prior to sending your logs to Stackdriver.

Using Stackdriver Logging for dedicated game server instances: new tutorial

Joseph Holley, Cloud Solutions Architect

Capturing logs from dedicated game server instances in a central location can be useful for troubleshooting, keeping track of instance runtimes and machine load, and capturing historical data that occurs during the lifetime of a game.

But collecting and making sense of these logs can be tricky, especially if you are launching the same game in multiple regions, or have limited resources on which to collect the logs themselves.

One possible solution to these problems is to collect your logs in the cloud. Doing this enables you to mine your data with tools that deliver speed and power not possible from an on-premise logging server. Storage and data management is simple in the cloud and not bound by physical hardware. Additionally, you can access cloud logging resources globally. Studios and BI departments across the globe can access the same logging database regardless of physical location, making collaboration for distributed teams significantly easier.


We recently put together a tutorial that shows you how to integrate Stackdriver Logging, our hosted log management and analysis service for data running on Google Cloud Platform (GCP) and AWS, into your own dedicated game server environment. It also offers some key storage strategies, including how to migrate this data to BigQuery and other Google Cloud tools. Check it out, and let us know what other Google Cloud tools you’d like to learn how to use in your game operations. You can reach me on Twitter at @gcpjoe.

Now shipping: Compute Engine machine types with up to 96 vCPUs and 624GB of memory

By Hanan Youssef and Scott Van Woudenberg, Product Managers, Compute Engine

Got compute- and memory-hungry applications? We’ve got you covered, with new machine types that have up to 96 vCPUs and 624 GB of memory—a 50% increase in compute resources per Google Compute Engine VM. These machine types run on Intel Xeon Scalable processors (codenamed Skylake), and offer the most vCPUs of any cloud provider on that chipset. Skylake in turn provides up to 20% faster compute performance, 82% faster HPC performance, and almost 2X the memory bandwidth compared with the previous generation Xeon.1

96 vCPU VMs are available in three predefined machine types: 

  • Standard: 96 vCPUs and 360 GB of memory
  • High-CPU: 96 vCPUs and 86.4 GB of memory
  • High-Memory: 96 vCPUs and 624 GB of memory


You can also use custom machine types and extended memory with up to 96 vCPUs and 624GB of memory, allowing you to better create exactly the machine shape you need, avoid wasted resources, and pay for only what you use.


The new 624GB Skylake instances are certified for SAP HANA scale-up deployments. And if you want to run even larger HANA analytical workloads, scale-out configurations of up to 9.75TB of memory with 16 n1-highmem-96 nodes are also now certified for data warehouses running BW4/HANA.

You can use these new 96-core machines in beta today in four GCP regions: Central US, West US, West Europe, and East Asia. To get started, visit your GCP Console and create a new instance. Or check out our docs for instructions on creating new virtual machines using the gcloud command line tool.


Need even more compute power or memory? We’re also working on a range of new, even larger VMs, with up to 4TB of memory. Tell us about your workloads and join our early testing group for new machine types.

1 Based on comparing Intel Xeon Scalable Processor codenamed "Skylake" versus previous generation Intel Xeon processor codenamed "Broadwell." 20% based on SpecINT. 82% based on on High Performance Linpack for 4 node cluster with AVX512. Performance improvements include improvements from use of Math Kernel Library and Intel AVX512. Performance tests are measured using specific computer systems, components, software, operations and functions, and may have been optimized for performance only on Intel microprocessors. Any change to any of those factors may cause the results to vary. You should consult other information to assist you in fully evaluating your contemplated purchases. For more information go to http://www.intel.com/benchmarks↩

Partnering on open source: Managing Google Cloud Platform with Chef

By Nelson Araujo, Software Engineer

Managing cloud resources is a critical part of the application lifecycle. That’s why today, we released and open sourced a set of comprehensive cookbooks for Chef users to manage Google Cloud Platform (GCP) resources.

Chef is a continuous automation platform powered by an awesome community. Together, Chef and GCP enable you to drive continuous automation across infrastructure, compliance and applications.

The new cookbooks allow you to define an entire GCP infrastructure using Chef recipes. The Chef server then creates the infrastructure, enforces it, and ensures it stays in compliance. The cookbooks are idempotent, meaning you can reapply them when changes are required and still achieve the same result.

The new cookbooks support the following products:



We also released a unified authentication cookbook that provides a single authentication mechanism for all the cookbooks.

These new cookbooks are Chef certified, having passed the Chef engineering team’s rigorous quality and review bar, and are open-source under the Apache-2.0 license on GCP's Github repository.

We tested the cookbooks on CentOS, Debian, Ubuntu, Windows and other operating systems. Refer to the operating system support matrix for compatibility details. The cookbooks work with Chef Client, Chef Server, Chef Solo, Chef Zero, and Chef Automate.

To learn more about these Chef cookbooks, register for the webinar with myself and Chef’s JJ Asghar on 15 October 2017.

Getting started with Chef on GCP

Using these new cookbooks is as easy as following these four steps:
  1. Install the cookbooks.
  2. Get a service account with privileges for the GCP resources that you want to manage and enable the the APIs for each of the GCP services you will use.
  3. Describe your GCP infrastructure in Chef:
    1. Define a gauth_credential resource
    2. Define your GCP infrastructure
  4. Run Chef to apply the recipe.
Now, let’s discuss these steps in more detail.

1. Install the cookbooks

You can find all the GCP cookbooks for Chef on Chef Supermarket. We also provide a “bundle” cookbook that installs every GCP cookbook at once. That way you can choose the granularity of the code you pull into your infrastructure.

Note: These Google cookbooks require neither administrator privileges nor special privileges/scopes on the machines that Chef runs on. You can install the cookbooks either as a regular user on the machine that will execute the recipe, or on your Chef server; the latter option distributes the cookbooks to all clients.

The authentication cookbook requires a few of our gems. You can install them using various methods, including using Chef itself:


chef_gem 'googleauth'
chef_gem 'google-api-client'


For more details on how to install the gems, please visit the authentication cookbook documentation.

Now, you can go ahead and install the Chef cookbooks. Here’s how to install them all with a single command:


knife cookbook site install google-cloud


Or, you can install only the cookbooks for select products:


knife cookbook site install google-gcompute    # Google Compute Engine
knife cookbook site install google-gcontainer  # Google Container Engine
knife cookbook site install google-gdns        # Google Cloud DNS
knife cookbook site install google-gsql        # Google Cloud SQL
knife cookbook site install google-gstorage    # Google Cloud Storage


2. Get your service account credentials and enable APIs

To ensure maximum flexibility and portability, you must authenticate and authorize GCP resources using service account credentials. Using service accounts allows you to restrict the privileges to the minimum necessary to perform the job.

Note: Because service accounts are portable, you don’t need to run Chef inside GCP. Our cookbooks run on any computer with internet access, including other cloud providers. You might, for example, execute deployments from within a CI/CD system pipeline such as Travis or Jenkins, or from your own development machine.

Click here to learn more about service accounts, and how to create and enable them.

Also make sure to enable the the APIs for each of the GCP services you intend to use.

3a. Define your authentication mechanism

Once you have your service account, add the following resource block to your recipe to begin authenticating with it. The resource name, here 'mycred' is referenced in the objects in the credential parameter.


gauth_credential 'mycred' do
  action :serviceaccount
  path '/home/nelsonjr/my_account.json'
  scopes ['https://www.googleapis.com/auth/compute']
end


For further details on how to setup or customize authentication visit the Google Authentication cookbook documentation.

3b. Define your resources

You can manage any resource for which we provide a type. The example below creates an SQL instance and database in Cloud SQL. For the full list of resources that you can manage, please refer to the respective cookbook documentation link or to this aggregate summary view.


gsql_instance ‘my-app-sql-server’ do
  action :create
  project 'google.com:graphite-playground'
  credential 'mycred'
end

gsql_database 'webstore' do
  action :create
  charset 'utf8'
  instance ‘my-app-sql-server’
  project 'google.com:graphite-playground'
  credential 'mycred'
end


Note that the above code has to be described in a recipe within a cookbook. We recommend you have a “profile” wrapper cookbook that describes your infrastructure, and reference the Google cookbooks as a dependency.

4. Apply your recipe

Next, we direct Chef to enforce the recipe in the “profile” cookbook. For example:

$ chef-client -z --runlist ‘recipe[mycloud::myapp]’

In this example, mycloud is the “profile” cookbook, and myapp is the recipe that contains the GCP resource declarations.

Please note that you can apply the recipe from anywhere that Chef can execute recipes (client, server, automation), once or multiple times, or periodically in the background using an agent.

Next steps

Now you're ready to start managing GCP resources with Chef, and start reaping the benefits of cross-cloud configuration management. Our plan is to continue to improve the cookbooks and add support for more Google products. We're also preparing to release the technology used to create these cookbooks as open source. If you have questions about this effort please visit Chef on GCP discussions forum, or reach out to us on [email protected].

Introducing custom roles, a powerful way to make Cloud IAM policies more precise

By Rohit Khare, Product Manager

As enterprises move their applications, services and data to the cloud, it’s critical that they put appropriate access controls in place to help ensure that the right people can access the right data at the right time. That’s why we’re excited to announce the beta release of custom roles for Cloud IAM.

Custom roles offer customers full control of 1,287 public permissions across Google Cloud Platform services. This helps administrators grant users the permissions they need to do their jobs — and only those permissions. Fine-grained access controls help enforce the principle of least privilege for resources and data on GCP.

“Verily is using custom roles to uphold the highest standards of patient trust by carefully managing the granularity of data access granted to people and programs based on their ‘need-to-know’.” — Harriet Brown, Product Manager for Trust, Compliance, and Data Security at Verily Life Sciences 

Understanding IAM roles 

IAM offers three primitive roles for Owner, Editor, and Viewer that make it easy to get started, and over one hundred service-specific predefined roles that combine a curated set of permissions necessary to complete different tasks across GCP. In many cases, predefined roles are sufficient for controlling access to GCP services. For example, the Cloud SQL Viewer predefined role combines 14 permissions necessary to allow users to browse and export databases.

Custom roles complement the primitive and predefined roles when you need to be even more precise. For example, an auditor may only need to access a database to gather audit findings so they know what data is being collected, but not to read the actual data or perform any other operations. You can build your own “Cloud SQL Inventory” custom role to grant auditors browse access to databases without giving them permission to export their contents.

How to create custom roles 

To begin crafting custom roles, we recommend starting from the available predefined roles. These predefined roles are appropriate for most use cases and often only need small changes to the permissions list to meet an organization's requirements. Here’s how you could implement a custom role for the above use case:

Step 1: Select the predefined role that you’d like to customize, in this case Cloud SQL Viewer:
Step 2: Clone the predefined role and give it a custom name and ID.  Add or remove the desired permissions for your new custom role. In this case, that’s removing cloudsql.instances.export.

How to use custom roles 

Custom roles are available now in the Cloud Console, on the Roles tab under the ‘IAM & admin’ menu; as a REST API; and on the command line as gcloud beta iam. As you create a custom role, you can also assign it a lifecycle stage to inform your users about the readiness of the role for production usage.

IAM supports custom roles for projects and across entire organizations to centralize development, testing, maintenance, and sharing of roles.


Maintaining custom roles 

When using custom roles, it’s important to track what permissions are associated with the roles you create, since available permissions for GCP services evolve and change over time. Unlike GCP predefined roles, you control if and when permissions are added or removed. Returning to our example, if new features are added to the Cloud SQL service — with corresponding new permissions — then you decide whether to add the new permissions to your customized “SQL Inventory” role as you see fit. During your testing, the Cloud Console’s appearance may vary for users who are granted custom roles, since UI elements may be enabled or disabled by specific permissions. To help maintain your custom roles, you can refer to the new IAM permissions change log to find all changes to beta and GA services’ permissions.

Get started! 

Interested in customizing Cloud IAM roles in your GCP project? Check out the detailed step-by-step instructions on how to get started here. We hope Cloud IAM custom roles make it easier for organizations to align access controls to their business processes. In conjunction with resource-level IAM policies, which can control access down to specific resources such as Pub/Sub topics or Machine Learning models, security administrators now have the power to publish policies as precise as granting a single user just one permission on a resource — or on whole folders full of projects. We welcome your feedback.

Profiling Kubernetes init time: Google Cloud Performance Atlas

By Colt McAnlis, Developer Advocate

Kubernetes offers an excellent set of features for container orchestration and deployment, which lends itself to creating extremely fast boot times for new instances. That being said, this fast boot time can often be lost in production if your containers do a lot of work during the initialization phase.

To achieve container boot-time harmony, it’s important to properly profile and understand how long your containers take to initialize. In practice, that process can be a bit troublesome, so here are a few tips and tricks to help you quickly track down that data.


Too busy to read? Check out the video summary on Youtube!!

Understanding pods and containers

A Kubernetes pod is made up of a series of containers, which provide endpoints and services for the instance itself. The pod is considered “ready” once all the containers have been initialized, and the health checks pass. To help facilitate proper bootup, the initialization process breaks up containers into two main groups:

  • Init containers, which execute in a serial order, as defined by the setup scripts
  • Parallel containers, which are executed in random parallel order.




This design has some interesting quirks and can sometimes be problematic. For instance, if a single init container takes a long time to boot up, it blocks the initialization of all the containers that follow. As such, it’s critical to understand the performance of both types of containers, as it may have a serious impact on your pod boot performance.

Timing init containers

Currently, init containers do not emit detailed information about how long it took them to initialize in the pod boot phase. As such, you must do any boot-phase analysis manually using the get pod command:


kubectl get pod <pod-name>


This command returns the pod status, and if you have init containers defined, the status of the init containers (in the STATUS field). For example, a status of “Init:1/2" indicates that one of two init containers has completed successfully:


NAME         READY     STATUS     RESTARTS   AGE

<pod-name>   0/1       Init:1/2       0       7s


To determine how long each container takes to initialize, we can successively poll the get pod command about every 10 ms or so, parse the output, and compute the timing delta between when the status value changes. Below is a graph that shows off a small prototype consisting of four init containers which the above function was called on repeatedly:



In the image above, you can clearly see that the stats-gathering container (Stats Framework) and the DB initialization (Local DB Init) containers are taking the most time to get off to the races. Since these are initialization containers, all subsequent services are delayed about 4-12 seconds, as these stages block the initialization of other work groups.

Timing parallel containers

Timing parallel containers is much trickier, since each one can start and stop in whatever order it wants, and container-specific boot information is not emitted via logging.

To get this information, we must adopt a similar method to how health checks work: For each container, expose a new entry point called “/health”, which returns the string “Success”. Repeatedly polling the endpoints for each container from an external location yields three different states:

  • error - The service is not up and running yet (red bar below)
  • 400 / 500 - The service is booting, but the endpoint is not available yet (yellow bar below)
  • “Success”

The goal is to add a /health entry point to each container, and have a script poll each one to get boot times. We can create a chart on how long the container took to start, and how long each stage was:



In the chart above, we can see the delay time (how long it took initialization to start for a container) as well as a break out between the time it takes for our container to initialize vs. the services in the container.

Every millisecond counts

With this in mind, here are some best practices for optimizing pod boot times:

  • Be mindful that init containers are in the critical path. Since the containers initialize linearly, the time spent executing one can delay the startup time of others. A single bad actor can significantly delay startup time. Consider how much work executes during the containers’ init phase vs. later on, in the parallel phase. (Note: Google Developer Advocate Kelsey Hightower has a great article on navigating this complexity.)
  • Avoid parallel init dependencies. Containers that initialize in parallel are done so randomly, which can impact your pod boot time if the containers have dependencies between them. If container A needs Container B, there could be a problem if A gets initialized before B, causing A to wait an unspecified amount of time. If possible, consider moving these dependencies to the init phase, or find a way to remove the dependency completely.


If you’d like to know more about ways to optimize your Google Cloud applications, check out the rest of the Google Cloud Performance Atlas blog posts and videos. Because when it comes to performance, every millisecond counts.


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

By Dan Paik, Product Manager, Container Engine

Next week, we will roll out Kubernetes 1.8 to Google Container Engine for early access customers. In addition, we are advancing significant new functionality in Google Cloud to give Container Engine customers a great experience across Kubernetes releases. As a result, Container Engine customers get new features that are only available on Google Cloud Platform, for example highly available clusters, cluster auto-scaling and auto-repair, GPU hardware support, container-native networking and more.

Since we founded Kubernetes back in 2014, Google Cloud has been the leading contributor to the Kubernetes open source project in every release including 1.8. We test, stage and roll out Kubernetes on Google Cloud, and the same team that writes it, supports it, ensuring you receive the latest innovations faster without risk of compatibility breaks or support hassles.

Let’s take a look at the new Google Cloud enhancements that make Kubernetes run so well.

Speed and automation 

Earlier this week we announced that Google Compute Engine, Container Engine and many other GCP services have moved from per-minute to per-second billing. We also lowered the minimum run charge to one minute from 10 minutes, giving you even finer granularity so you only pay for what you use.

Many of you appreciate how quickly you can spin up a cluster on Container Engine. We’ve made it even faster - improving cluster startup time by 45%, so you’re up and running faster, and better able to take advantage of the pricing minimum-time charge. These improvements also apply to scaling your existing node pools.

A long-standing ask has been high availability masters for Container Engine. We are pleased to announce early access support for high availability, multi-master Container Engine clusters, which increase our SLO to 99.99% uptime. You can elect to run your Kubernetes masters and nodes in up to three zones within a region for additional protection from zonal failures. Container Engine seamlessly shifts load away from failed masters and nodes when needed. Sign up here to try out high availability clusters.

In addition to speed and simplicity, Container Engine automates Kubernetes in production, giving developers choice, and giving operators peace of mind. We offer several powerful Container Engine automation features:

  • 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. 
  • 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

Container Engine now takes better advantage of GCP’s unique, software-defined network with first-class Pod IPs and multi-cluster load balancing.

  • 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 acceleration

Machine learning, data analytics and Kubernetes work especially well together on Google Cloud. Container Engine with GPUs turbocharges compute-intensive applications like machine learning, image processing, artificial intelligence and financial modeling. This release brings you managed CUDA-as-a-Service in containers. Big data is also better on Container Engine with new features that make GCP storage accessible from Spark 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 

As more enterprises use Container Engine, we are actively improving extensibility so you can match Container Engine to your environment and standards.


Security and reliability 

We designed Container Engine with enterprise security and reliability in mind. This release adds several new enhancements.

  • 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 

In Kubernetes 1.7, we added view-only workload, networking, and storage views to the Container Engine user interface. In 1.8, we display even more information, enable more operational and development tasks without having to leave the UI, and improve integration with Stackdriver and Cloud Shell.



The following features are all generally available:

  • 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. 

In addition, Audit Logging is available to early access customers. This features enables you to view your admin activity and data access as part of Cloud Audit Logging. Please complete this form to take part in the Audit Logging early access program.


Container Engine everywhere 

Container Engine customers are global. To keep up with demand, we’ve expanded our global capacity to include our latest GCP regions: Frankfurt (europe-west3), Northern Virginia (us-east4) and São Paulo (southamerica-east1). With these new regions Container Engine is now available in a dozen locations around the world, from Oregon to Belgium to Sydney.



Customers of all sizes have been benefiting from containerizing their applications and running them on Container Engine. Here are a couple of recent examples:

Mixpanel, a popular product analytics company, processes 5 trillion data points every year. To keep performance high, Mixpanel uses Container Engine to automatically scale resources.

“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, a provider of real-time commercial real estate information, was able to cut its cloud hosting costs in half by moving to microservices on Container Engine.

“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. 

Bitnami, an application package and deployment platform, shows you how to use Container Engine networking features to create a private Kubernetes cluster that enforces service privacy so that your services are available internally but not to the outside world.

Try it today! 

In a few days, all Container Engine customers will have access to Kubernetes 1.8 in alpha clusters. These new updates will help even more businesses run Kubernetes in production to get the most from their infrastructure and application delivery. If you want to be among the first to access Kubernetes 1.8 on your production clusters, please join our early access program.

You can find the complete list of new features in the Container Engine release notes. For more information, visit our website or sign-up for our free trial at no cost.

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

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.]

When it comes to network policy, a lot has changed. Back in the day, we protected enterprise data centers with a big expensive network appliance called a firewall that allowed you to define rules about what traffic to allow in and out of the data center. In the cloud world, virtual firewalls provide similar functionality for virtual machines. For example, Google Compute Engine allows you to configure firewall rules on VPC networks.

In a containerized microservices environment such as Google Container Engine, network policy is particularly challenging. Traditional firewalls provide great perimeter security for intrusion from outside the cluster (i.e. “north-south” traffic), but aren’t designed for “east-west” traffic within the cluster at a finer-grained level. And while Container Engine automates the creation and destruction of containers (each with its own IP address), not only do you have many more IP endpoints than you used to, the automated create-run-destroy life-cycle of a container can result in churn up to 250x that of virtual machines.

Traditional firewall rules are no longer sufficient for containerized environments; we need a more dynamic, automated approach that is integrated with the orchestrator. (For those interested in why we can’t just continue with traditional virtual network / firewall approaches, see Christopher Liljenstolpe’s blog post, Micro-segmentation in the Cloud Native World.)


We think the Kubernetes Network Policy API and the Project Calico implementation present a solution to this challenge. Given Google’s leadership role in the community, and its commitment to running Container Engine on the latest Kubernetes release, it’s only natural that they would be the first to include this capability in their production hosted Kubernetes service, and we at Tigera are delighted to have helped support this effort.


Kubernetes Network Policy 1.0

What exactly does Kubernetes Network Policy let you do? Kubernetes Network Policy allows you to easily specify the connectivity allowed within your cluster, and what should be blocked. (It is a stable API as of Kubernetes v1.7.)

You can find the full API definition in the Kubernetes documentation but the key points are as follows:
  • 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. 


Here is an example NetworkPolicy resource to give you a sense of how this all fits together:

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:
  1. Enable the network policy add-on on the master.
  2. 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 

Environments running Kubernetes 1.7 can use the NetworkPolicy API capabilities that we discussed above, essentially ingress rules defined by selector expressions. However, you can imagine wanting to do more, such as:

  • Applying egress rules (restricting which outbound connections a pod can make) 
  • Referring to IP addresses or ranges within rules 

The good news is that the new Kubernetes 1.8 includes these capabilities, and Google and Tigera are working together to make them available in Container Engine. And, beyond that, we are working on even more advanced policy capabilities. Watch this space!

Attend our joint webinar! 

Want to learn more? Google Product Manager Matt DeLio will join Casey Davenport, the Kubernetes Networking SIG leader and a software engineer at Tigera, to talk about best practices and design patterns for securing your applications with network policy. Register here for the October 5th webinar.

PHP 7.1 for Google App Engine is generally available

By Brent Shaffer and Takashi Matsuo, Developer Programs Engineer, Google Cloud Platform

Earlier this year, we announced PHP 7.1 Google App Engine in beta. We PHP lovers at Google are proud to announce that PHP 7.1 is now generally available on Google App Engine, our easy-to-use platform for building, deploying, managing and automatically scaling services on Google’s infrastructure. The PHP 7.1 runtime is available for App Engine flexible environment.



Along with achieving general availability for PHP 7.1, the new PHP runtime includes a few exciting new features.

Extension enabler


The list of PHP extensions you can use with the App Engine runtime now includes any PHP extension that is stable (1.0 and above) and does not require a EULA. You can find a complete list on the PHP runtime page.

This is great news, but to make it even better you can now quickly and easily activate any of these extensions in your deployment by requiring them with Composer.

composer require "ext-gd:*" --ignore-platform-reqs

This is equivalent to adding the name of the extension, prefixed with “ext-”, to your application’s composer.json:
{
    "require": {
        "ext-gd": "*"
    }
}

You can still install a custom extension or a specific version of a supported extension, but this will require extending the PHP runtime.

Stackdriver Logging and Error Reporting support


Logging to Stackdriver from your PHP application is very simple. The first requirement is to install the Composer package google/cloud version 0.33 or higher.

composer require google/cloud

Now set enable_stackdriver_integration to true in the runtime_config section of app.yaml:

runtime_config:
  enable_stackdriver_integration: true

This configuration tells the PHP runtime to dispatch the batch-processing daemon to handle your logs behind the scenes. This ensures that when your application writes a log, calls to the Stackdriver API happen in another process so as not to add latency to your application.
Now you can create a PsrBatchLogger instance in your code and log to Stackdriver:

use 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 thing

Additionally, the enable_stackdriver_integration flag sets up an auto-prepend file for error reporting. This means uncaught exceptions and fatal errors are formatted and visible in Cloud Console Error Reporting!

throw new \Exception('Uncaught exceptions are logged to Stackdriver!');


$obj->thisDoesNotExist(); // Fatal errors are also logged to Stackdriver!

If you’d rather use individual Google Cloud packages, ensure you have both google/cloud-logging and google/cloud-error-reporting installed. When installing locally, use --ignore-platform-reqs or install gRPC according to the installation instructions.


composer require google/cloud-logging google/cloud-error-reporting \

    "ext-grpc:*" --ignore-platform-reqs

Stackdriver Logging for Laravel

After you’ve configured the enable_stackdriver_integration, you can enable Stackdriver integration in an app based on the Laravel PHP framework by modifying bootstrap/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;

For Error Reporting, add an import and call our `exceptionHandler` in the `report` function in `app/Exceptions/Handler.php`:


use Google\Cloud\ErrorReporting\Bootstrap;

// .. other code
    public function report(Exception $exception)
    {
        if (isset($_SERVER['GAE_SERVICE'])) {
            Bootstrap::exceptionHandler($exception);<
        } else {
            parent::report($exception);
        }
    }

That's it! The logs are sent to Stackdriver Logging with the logName 'app'. Unhandled exceptions are sent to the logName 'app-error', and will show up in Stackdriver Error Reporting.

gRPC Support

Google’s highly performant RPC protocol gRPC is built right into the PHP runtime. This allows you to quickly get started making calls to Cloud Spanner and other gRPC-specific APIs. You can enable the extension in composer.json and download the client library:

composer require "ext-grpc:*" google/cloud-spanner --ignore-platform-reqs

Now you can make calls to Spanner in your application:

<?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');

By replacing YOUR_INSTANCE_ID and YOUR_DATABASE_ID with the proper values, your application now displays the text “Hello Spanner”!

Our commitment to PHP and open source

At Google, we’re committed to open source -- and that goes for the new core PHP Docker runtime, google-cloud composer package and Google API client:


We’re thrilled to welcome PHP developers to Google Cloud Platform, and we’re invested in making you as productive as possible. This is just the start -- stay tuned to the blog and our GitHub repositories to catch the next wave of PHP support on GCP.

We can’t wait to hear from you. Feel free to reach out to us on Twitter, or request an invite to the Google Cloud Slack community and join the #PHP channel.