VMware support, proxy, artifacts caching, and UI improvements headline this release Mirantis Container Cloud 2.7 is now generally available, sporting a new provider enabling deployment and lifecycle management of Container Cloud Management, Regional and (Mirantis Kubernetes Engine) child clusters. Container Cloud can now perform all its functions on VMware clouds, including non-disruptive self- and child-cluster … Continued
Quelle: Mirantis
Developers and data scientists are increasingly turning to Google Kubernetes Engine (GKE) to run demanding workloads such as machine learning, visualization/rendering and high-performance computing, leveraging GKE’s support for NVIDIA GPUs. GKE brings the flexibility, autoscaling and management simplicity, while GPUs bring superior processing power. Today, we are launching support for multi-instance GPUs in GKE (currently in Preview), which will help you drive better value from your GPU investments.Open-source Kubernetes allocates one full GPU per container—even if the container only needs a fraction of the GPU for its workload. This can lead to wasted resources and cost overruns, especially if you are using the latest generation of powerful GPUs. This is of particular concern for inference workloads, which process only a handful of samples in real-time (in contrast, training workloads process millions of samples in large batches). Thus, for inference and other lightweight GPU workloads, GPU sharing is essential to improve utilization and lower costs. With the launch of multi-instance GPUs in GKE, now you can partition a single NVIDIA A100 GPU into up to seven instances that each have their own high-bandwidth memory, cache and compute cores. Each instance can be allocated to one container, for a maximum of seven containers per one NVIDIA A100 GPU. Further, multi-instance GPUs provide hardware isolation between containers, and consistent and predictable QoS for all containers running on the GPU. Add to that the fact that A2 VMs, Google Cloud’s largest GPU-based Compute Engine instances, support up to 16 A100 GPUs per instance. That means you can have up to 112 schedulable GPU instances per node, where each can run one independent workload. By leveraging GKE’s industry-leading auto-scaling and auto-provisioning capabilities, multi-instance GPUs can be automatically scaled up or down, offering superior performance at lower costs. For CUDA® applications, multi-instance GPUs are largely transparent. Each GPU instance appears as a regular GPU resource, and the programming model remains unchanged, making multi-instance GPUs easy and convenient to use.What customers are sayingEarly adopters of multi-instance GPU nodes are using the technology to turbocharge their use of GKE for demanding workloads. Betterview, a provider of property insight and workflow tools for the insurance sector, uses GKE and NVIDIA GPUs to process aerial imagery.”The multi-instance GPU architecture with A100s evolves working with GPUs in Kubernetes/GKE. By reducing the number of configuration hoops one has to jump through to attach a GPU to a resource, Google Cloud and NVIDIA have taken a needed leap to lower the barrier to deploying machine learning at scale. Alongside reduced configuration complexity, NVIDIA’s sheer GPU inference performance with the A100 is blazing fast. Partnering with Google Cloud has given us many exceptional options to deploy AI in the way that works best for us.” -Jason Janofsky, VP Engineering & CTO, BetterviewCreating multi-instance GPU partitionsThe A100 GPU consists of seven compute units and eight memory units, which can be partitioned into GPU instances of varying sizes, providing the flexibility and choice you need to scale your workloads. For example, you can create two multi-instance GPU instances with 20GB of memory each, three instances with 10GB, or seven with 5GB. The GPU partition instances use the following syntax: [compute]g.[memory]gb. For example, a GPU partition size 1g.5gb refers to a GPU instance with one compute unit (1/7th of streaming multiprocessors on the GPU), and 1 memory unit (5GB). The partition size for A100 GPUs can be specified through the GKE cluster or node pool API. Deploying containers on a multi-instance GPU nodeYou can deploy up to one container per multi-instance GPU instance on a node. With a partition size of 1g.5gb, there are seven multi-instance GPU partitions available on the node with one A100 GPU. As a result, you can deploy up to seven containers that request GPUs on this node. Each node is labeled with the size of it’s available GPU partitions. This labeling allows workloads to request the right sized GPU instances through node selectors or node affinity. Getting started Now, with multi-instance GPUs on GKE, you can easily match your workload acceleration needs with right sized resources. Moreover, you can exploit the power of GKE to automatically scale the infrastructure to efficiently serve your acceleration needs while delivering a better user experience and minimizing the operational costs. Get started today!Related ArticleA2 VMs now GA—the largest GPU cloud instances with NVIDIA A100 GPUsA2 VMs with NVIDIA A100 GPUs are now generally available for your most demanding workloads including machine learning and HPC.Read Article
Quelle: Google Cloud Platform
A fundamental security premise is to verify the identity of a user before determining if they are permitted to access a resource or service. This process is known as authentication. But authentication is necessary for more than just human users. When one application needs to talk to another, we need to authenticate its identity as well. In the cloud, this is most frequently accomplished through a service account.Service accounts represent non-human users and on Google Cloud are managed by Cloud Identity and Access Management (IAM). They are intended for scenarios where an application needs to access resources or perform actions under its own identity. For example, an application that runs on a VM instance might need access to a Cloud Storage bucket that is configured to store its data. Unlike normal users, service accounts cannot authenticate using a password or single sign-on (SSO). There are a variety of authentication methods that service accounts can employ instead, and it’s important to use the right one based on your needs. The following guidelines can help make sure you choose the best way to authenticate service accounts. Only use service accounts where appropriateBefore you jump to the conclusion that you need a service account, ask yourself whether the application is acting on its own behalf or on the end user’s behalf:An application that continuously gathers metrics and stores them in a Cloud Storage bucket acts on its own behalf—it’s a background job that runs unattended, with no end user involved.An application that lets a user access their personal documents is not acting on its own behalf, but on behalf of the end user.Whenever an application is acting on behalf of an end user, using a service account might not be the right choice. Instead, it’s better to use an OAuth consent flow to request the end user’s consent, and then let the application act under their identity. By using OAuth, you ensure that:End users can review which resources they are about to grant the application access to, and can explicitly express or deny their consent.Users can revoke their consent on their My Account page at any time.No service account gets unfettered access to user data.During your daily work, you might use tools such as gcloud, gsutil or terraform. It’s you who runs these tools, so the tools should also use your credentials. Instead of using a service account key to run these tools, let them use your credentials by running gcloud auth login (for gcloud and gsutil) or gcloud auth application-default login (for terraform and other third-party tools). Limiting the use of service accounts and service account keys to situations in which they’re absolutely necessary keeps user data more secure, reduces the chance of unauthorized activity, and makes it easier to use audit logs to determine which users performed certain operations.Use attached service accounts when possibleFor applications deployed on Google Cloud that need to use a service account, attach the service account to the underlying compute resource. By attaching a service account, you enable the application to obtain tokens for the service account and to use these tokens to access Google Cloud APIs and resources.To obtain access tokens in the application, use the Google Cloud client libraries if possible. The client libraries automatically detect if the application is running on a compute resource with an attached service account.In situations where using the client libraries is not practical, adjust your application to programmatically obtain tokens from the metadata server. Compute resources that support access to the metadata server include:Cloud Run Cloud FunctionsCompute EngineAppEngine second-genAppEngine Flex For a full list of compute resources that let you attach a service account, see Managing service account impersonation.Use Workload Identity to attach service accounts to Kubernetes podsIf you use Google Kubernetes Engine (GKE) you might be running a combination of different applications on a single GKE cluster. The individual applications are likely to differ in which resources and APIs they need access to. If you attach a service account to a GKE cluster or one of its node pools, then by default, all pods running on the cluster or node pool can impersonate the service account. Sharing a single service account across different applications makes it difficult to assign the right set of privileges to the service account:If you only grant access to resources that all applications require, then some applications might fail to work because they lack access to certain resources.If you grant access to all resources that any particular application needs, then you might be over-granting access.A better approach to manage resource access in a GKE environment is to use Workload Identity, which lets you associate service accounts with individual pods:Do not attach service accounts to GKE clusters or node pools.In Cloud IAM, create a dedicated service account for each Kubernetes pod that requires access to Google APIs or resources. In GKE, create a Kubernetes service account for each Kubernetes pod that requires access to Google APIs or resources and attach it to the pod.Use Workload Identity to create a mapping between the service accounts and their corresponding Kubernetes service accounts.Use Workload Identity federation to use services accounts for applications not running on Google CloudIf your application runs on-premises or on another cloud provider, then you cannot attach a service account to the underlying compute resources. However, the application might have access to environment-specific credentials such as:AWS temporary credentialsAzure AD access tokensOpenID access tokens or ID tokens issued by an on-premises identity provider like AD FS or KeyCloakIf your application has access to one of these credentials and needs access to Google Cloud APIs or resources, use workload identity federation.Workload identity federation lets you create a one-way trust relationship between a Google Cloud project and an external identity provider. Once you’ve established that trust, applications can use credentials issued by the trusted identity provider to impersonate a service account by following a three-step process:Obtain a credential from the trusted identity provider, for example an OpenID Connect ID token.Use the STS API to exchange the credential against a short-lived Google STS token.Use the STS token to authenticate to the IAM Credentials API and obtain short-lived Google access tokens for a service account.By using workload identity federation, you can let applications use the native authentication mechanisms that the external environment provides, and you avoid having to store and manage service account keys.Use service account keys only if there is no viable alternativeOccasionally, you might encounter a situation where attaching a service account is not possible, and using Workload Identity or Workload Identity federation aren’t viable options either. For example, one of your on-premises applications might need access to Google Cloud resources, but your on-premises identity provider isn’t compatible with OpenID Connect (or SAML 2.0, which we’ll soon add support for), and therefore cannot be used for Workload Identity federation.In situations where other authentication approaches are not viable (and only in those situations), create a service account key for the application. A service account key lets an application authenticate as a service account, similar to how a user might authenticate with a username and password. Service account keys must be kept secret and protected from unauthorized access, so store them in a secure location such as a key vault and rotate them frequently.As an organization administrator you might want to control which users in your organization can use service account keys. This can be done using the service account key organization policies.Decision timeAuthenticating with service accounts is powerful, but it’s by no means the only way to do so, and should only be used if other approaches aren’t a good fit. If you’re still unsure about which authentication approach is best for your application, consult the following flowchart:For more details on using and securing service accounts, see Best practices for using and managing service accounts and Best practices for securing service accounts in our product documentation.Related ArticleRead Article
Quelle: Google Cloud Platform
In 2016 we announced a new discipline at Google, Customer Reliability Engineering, an offshoot of Site Reliability Engineering (SRE). Our goal with CRE was (and still is) to create a shared operational fate between Google and our Google Cloud customers, to give you more control over the critical applications you’re entrusting to us. Since then, here on the Google Cloud blog, we’ve published a wealth of resources to help you take the best practices we’ve learned from SRE teams at Google and apply them in your own environments. Below is the complete list of CRE life lessons posts we’ve published in the past five years in one convenient location.Common pitfallsKnow thy enemy: How to prioritize and communicate risksHow to avoid a self-inflicted DDoS AttackUsing load shedding to survive a success disasterService-level metricsAvailable . . . or not? That is the questionSLOs, SLIs, SLAs, oh myBuilding good SLOsConsequences of SLO violationsAn example escalation policyApplying the escalation policyDefining SLOs for services with dependenciesTune up your SLI metricsLearning—and teaching—the art of service-level objectivesUsing deemed SLIs to measure customer reliabilityReleasesReliable releases and rollbacksHow release canaries can save your baconSRE supportWhy should your app get SRE support?How SREs find the landmines in a serviceMaking the most of an SRE service takeoverDark launchesWhat is a dark launch, and what does it do for me?The practicalities of dark launchingPostmortemsFearless shared postmortemsGetting the most out of shared postmortemsError BudgetsGood housekeeping for error budgetsUnderstanding error budget overspendProduction IncidentsShrinking the impact of production incidents using SRE principlesShrinking the time to mitigate production incidentsWe still have plenty more articles to come, so keep your eye on our DevOps & SRE channel. You can also check out sre.google or read our SRE books online.
Quelle: Google Cloud Platform
Bei Vodafone nahm die Datennutzung um 30 Prozent zu. Doch der Kabelnetzbetreiber steht in der Breitbandmessung der Bundesnetzagentur ganz gut da. (Festnetz, Mobilfunk)
Quelle: Golem
Die von Amazon vorgeschriebenen Masken sind bei der Arbeit, im Büro oder am Band völlig unzureichend, kritisiert ein Corona-Experte. (Coronavirus, Amazon)
Quelle: Golem
Verglichen zur Logitech-Konkurrenz ist die Orochi V2 leichter und beherrscht optional Bluetooth, allerdings ruft Razer einen hohen Preis auf. (Maus, Razer)
Quelle: Golem
Die Nager schafften es in Kanada, sich durch ein gut geschütztes Glasfaser-Kabel zu arbeiten. (Glasfaser, Telekommunikation)
Quelle: Golem
Google fügt seinem FaaS-Dienst immer mehr Laufzeitumgebungen für Programmiersprachen hinzu. Neuester Zuwachs ist eine öffentliche Vorschau für PHP. (PHP, Google)
Quelle: Golem
The past year has given everyone lots to think about—about our priorities as people and as businesses. As the world retreated behind closed doors, we saw how shared interests and experiences can bring us together. As the world grappled with a common enemy, we witnessed just how differently individuals, communities and indeed entire countries can experience a situation. And as we faced seemingly unending obstacles to making it through the pandemic, we saw how making smart decisions based on data can drive meaningful solutions—fast.That’s why we here at Google Cloud are so proud to partner Univision, the country’s leading Spanish-language content and media company. By partnering with Google Cloud, Univision will be able to accelerate growth across its portfolio of properties, deliver an enhanced user experience for Spanish-speaking audiences and provide the enterprise solutions needed to create the Spanish-language media company of the future.According to Instituto Cervantes, there are over 580 million Spanish language speakers worldwide. Those viewers, like people everywhere, are avid consumers of streaming content. In Q4 of 2020 alone, viewing time for that content increased by 44%1, and in 2020, from 50%2 more sources. With that surge in demand, Univision needed a cloud provider whose infrastructure could reach Hispanic viewers around the world. With two-plus decades spent building out its network and data centers, as well as global content-delivery capabilities, Google Cloud has the infrastructure Univision needs to reach viewers across the Spanish-speaking world.At the same time, with such a diverse audience for their content, Univision needs to target that content to viewers’ specific preferences. By applying Google Cloud’s artificial intelligence (AI) and machine learning (ML) technology across its content, Univision intends to personalize content based on shows users have previously watched, enhancing their engagement and viewing experience. And as Univision transforms the user experience, it can use Google Cloud’s data and analytics suite to garner deeper insights into its audience and forge stronger relationships with them on an individual basis. With Looker and BigQuery, Univision employees will have access to real-time data to help them make business decisions about programming.Univision will also migrate video distribution and production operations to Google Cloud, where we’ll help them streamline media workflows and develop innovative new capabilities. Meanwhile, Google Cloud’s tight business and technical integration with other Google services will help ensure Univision reaches viewers on the device of their choice, wherever they are in the world. For example, in the coming years, Univision will expand its global YouTube partnership and will integrate with entertainment features on Google Search that help people better discover TV shows and movies. The company will also use Google Ad Manager for global ad decisioning and Google’s Dynamic Ad Insertion for PrendeTV and future video-on-demand offerings. Finally, Univision will distribute its content and services on Google Play across Android phones and tablets, as well as Google TV and other Android TV OS devices.We’re thrilled to partner with Univision to help them reach the Spanish-speaking world with their content. With our cloud portfolio, we can help them reach individual viewers around the world, with personalized content that they can consume however they see fit. Best of all, together, we can help them achieve this vision fast, leveraging established cloud, content delivery, and data analytics technologies. You can learn more about the partnership here.1. https://pages.conviva.com/rs/138-XJA-134/images/RPT_Conviva_SoS_Q4_2020.pdf2. https://hubresearchllc.com/reports/Related ArticleHelping media companies navigate the new streaming normalAs media and entertainment companies evolve their future plans as a result of COVID-19, they should keep new audience behaviors top of mi…Read Article
Quelle: Google Cloud Platform
