Cloud Computing Köln - Seite 1954 von 7019 - Neues zu Cloud Computing, Internet of Things und Technologien

Routine maintenance is critical in the upkeep of any healthy database system. Maintenance involves updating your operating system and upgrading your database software so that you can rest assured that your system is secure, performant, and up-to-date. When you run your database on Cloud SQL, we schedule maintenance for you once every few months during your weekly maintenance window, so that you can turn your attention to more interesting matters. However, from time-to-time, you may find that Cloud SQL’s regular maintenance cadence just doesn’t work for you. Maybe you need a bug fix from the latest database minor version to address a performance issue, or maybe there’s an operating system vulnerability that your security team wants patched as soon as possible. Whatever the case, having the flexibility to update before the next scheduled maintenance event would be ideal.Cloud SQL has now made self-service maintenance generally available. Self-service maintenance allows you the freedom to upgrade your Cloud SQL instance’s maintenance version to the latest on your own, so that you can receive the latest security patches, bug fixes, and new features on demand. When combined with deny maintenance periods, self-service maintenance gives you the flexibility to upgrade your instance according to your own maintenance schedule. You can perform self-service maintenance using just a single command through gcloud or the API.Cloud SQL has also launched maintenance changelogs, a new section in our documentation that describes the contents of maintenance versions released by Cloud SQL. For each database engine major version, Cloud SQL publishes a running list of the maintenance versions and the changes introduced in each, such as database minor version upgrades and security patches. With maintenance changelogs, you can know what’s new with the latest maintenance version and make informed decisions about when you need to maintain your instance on your own ahead of regularly scheduled maintenance. Cloud SQL also upkeeps an RSS feed for each maintenance changelog that you can subscribe your feed reader to and receive notifications when Cloud SQL releases new maintenance versions.How to perform self-service maintenanceSay you’re a PostgreSQL database administrator at a tax accounting software firm named Taxio. During Q1 of each year, you use a deny maintenance period to skip maintenance on your database instance named tax-services-prod in order to ensure your environment is as stable as possible during your busy season. Now that it’s May, you take a closer look at how your PostgreSQL 12.8 instance is operating on the older maintenance version.After studying the query performance patterns using Query Insights, you realize that your queries that use regular expressions are running far slower than you expected. You check out the PostgreSQL bugs page and you see that other users reported the same performance regression in PostgreSQL 12.8. Fortunately, it looks like the issue was patched in PostgreSQL 12.9 and later minor versions.You decide you’d like to go ahead and take care of the issue right away ahead of the next scheduled maintenance event, which is a few months away. First, you need to see what maintenance version tax-services-prod is running and what the latest maintenance version available is. You spin up gcloud and retrieve the instance’s configuration information with the following command:code_block[StructValue([(u’code’, u’gcloud sql instances describe tax-services-prod’), (u’language’, u”)])]Cloud SQL returns the following information:code_block[StructValue([(u’code’, u”connectionName: taxio:us-central1:tax-services-prodrncreateTime: ‘2019-03-22T03:30:48.231Z’rndatabaseInstalledVersion: POSTGRES_12_8rnu2026rnmaintenanceVersion: POSTGRES_12_8.R20210922.02_00rnu2026rnavailableMaintenanceVersions: rn- POSTGRES_12_10.R20220331.02_01rnu2026″), (u’language’, u”)])]You see that there is a new maintenance version, POSTGRES_12_10.R20220331.02_01, that is much more current than your current maintenance version, POSTGRES_12_8.R20210922.02_00. From the version name, it looks like the new maintenance version runs on PostgreSQL 12.10, but you want to be sure. You navigate to the PostgreSQL 12 maintenance changelog page in the documentation and confirm that the new maintenance version upgrades the database minor version to PostgreSQL 12.10.You decide to perform self-service maintenance. You enter the following command into gcloud:code_block[StructValue([(u’code’, u’gcloud sql instances patch tax-services-prod \rnu2013maintenance-version=POSTGRES_12_10.R20220331.02_01′), (u’language’, u”)])]Cloud SQL returns the following response:code_block[StructValue([(u’code’, u’The following message will be used for the patch API method.rn{“maintenanceVersion”: “POSTGRES_12_10.R20220331.02_01″, “name”: “tax-services-prod”, “project”: “taxio”, “settings”: {}}rnPatching Cloud SQL instance…working..’), (u’language’, u”)])]A few minutes later, your tax-services-prod is up-to-date, running PostgreSQL 12.10. You run some acceptance tests and you’re delighted to see that the performance for queries with regular expressions is much better.Learn moreWith self-service maintenance, you can update your instance with the latest maintenance version, outside of the flow of regularly scheduled maintenance. You can also use maintenance changelogs to review the contents of new maintenance versions. See our documentation to learn more about self-service maintenance and maintenance changelogs.Related ArticleUnderstanding Cloud SQL Maintenance: why is it needed?Get acquainted with the way maintenance works in Cloud SQL so you can effectively plan availability.Read Article
Quelle: Google Cloud Platform

17. Mai 2022

da Agency

Join us in evolving the usability of GitOps

Kubernetes configuration automation remains challengingCompanies of all sizes are leveraging Kubernetes to modernize how they build, deploy, and operate applications on their infrastructure. As these companies expand the numbers of development and production clusters they use, creating and enforcing consistent configurations and security policies across a growing environment becomes difficult. To address this challenge, it is increasingly common for platform teams to use GitOps methodology to deploy configuration and policies consistently across clusters and environments with a version-controlled deployment process. Using the same principles as Kubernetes itself, GitOps reconciles the desired state of clusters with a set of declarative Kubernetes configuration files in a versioned storage system, typically git. However, implementing the git workflow is often left as exercise for the user: repo, branch, and directory organization, versioning and tagging, change proposal and approval authorization, pre-merge validation checks, etc. It can be difficult to set up appropriately, especially when managing changes across 10s, to 100s, and even 1000s of applications that are deployed at large enterprises. Moreover, configuration is typically represented using code and code-like formats, such as templates, domain-specific languages, and general-purpose programming languages, which effectively require manual authoring and editing. Here is a very simple template, for generating Kubernetes RoleBindings:code_block[StructValue([(u’code’, u'{{- range .roleBindings }}rn—rnapiVersion: rbac.authorization.k8s.io/v1rnkind: RoleBindingrnmetadata:rn name: {{ .name }}rn namespace: {{ .namespace }}rnroleRef:rn apiGroup: rbac.authorization.k8s.iorn kind: {{ .roleKind }}rn name: {{ .role }}rnsubjects:rn- apiGroup: rbac.authorization.k8s.iorn kind: Grouprn name: {{ .namespace }}.admin@bigco.comrn{{- end }}’), (u’language’, u”)])]Cross-functional collaboration across platform and application teams can become a bottleneck especially as the needs of individual teams differ from one another, requiring frequent template changes that potentially affect all uses of the templates. For example, the template above does not support binding to ServiceAccounts. Adding that option could potentially affect all uses of the template.Since such configuration tools assume they exclusively generate and set the desired state, they are not interoperable with easier-to-use client surfaces, such as Graphical User Interfaces (GUIs) and Command-Line Interfaces (CLIs). Some of these tools support transitioning to configuration tools by providing the ability to download or output the YAML representations of resources.Once that transition is made, however, it’s a one-way door, and future edits must be made manually, to a different format, through a different process. We’ve heard from users that changes that take only seconds to make in a GUI can take days to make through configuration tools. Wouldn’t it be great if you didn’t have to choose between “the easy way” and “the right way”?To really make GitOps usable, we need to address the inherent dichotomy between preferred client surfaces and configuration tools.Making configuration authoring and editing a first class citizenWe previously open sourced kpt, a package-centric toolchain for helping platform teams manage their infrastructure. To address the usability challenges outlined previously, we are extending that toolchain with Porch, the package orchestrator, which enhances the toolchain by enabling a What You See Is What You Get (WYSIWYG) configuration authoring, automation, and delivery experience. This experience simplifies managing Kubernetes platforms and KRM-driven infrastructure at scale by manipulating declarative Configuration as Data, separated from the code that transforms it. Whereas GitOps automates on-the-fly configuration generation from existing configuration packages and repositories and deployment of the output of that process to Kubernetes, the package orchestrator automates configuration package creation, editing, transformation, upgrades, and other configuration package lifecycle operations, creating and managing the content to be deployed via GitOps.We created an open-source plugin for the Backstage platform portal framework that provides a WYSIWYG GUI experience. It builds on the package orchestrator to allow platform and application teams to easily author and edit configuration, while enforcing guardrails. You don’t need to write YAML, patches, or templates, or even branch, commit, tag, push, and merge changes.This approach is unique in that it avoids many of the pitfalls currently faced today in the ecosystem when building a GUI on top of GitOps. In particular, prevailing approaches require creating abstractions, often thin ones, that need to be custom-built on top of the Kubernetes resource model. This creates a situation where platform teams need to do a lot of additional work to create a management experience on top of Kubernetes, and lose out on the value of the ecosystem of tooling and educational content built around the standard Kubernetes (and extensions’) resource types.By leveraging Configuration as Data and package orchestration, we enable a GUI that complements the existing ecosystem rather than requiring thin abstractions that just get in the way. The GUI modifies configuration data very similarly to GUIs that directly operate on the live state in Kubernetes – the resource schemas are identical, since Kubernetes is natively declarative. Since it is early, the GUI supports a limited use case, provisioning and managing namespaces and their adjacent Kubernetes policy resources. Over time we plan to build in support for other critical use cases faced by cluster administrators today, which is mostly a matter of simply implementing form editors for additional resource types, and transformer functions for additional customization scenarios.As shown in our tutorial, blueprints can be created through a simple form-based UI, again, without templates. Just draft examples of the resources to deploy, similar to kustomize bases:Resources can be added, edited, or deleted, without writing YAML:Like kustomize, kpt uses KRM functions to transform the resources in order to create variants. You can select functions from the catalog and choose their inputs. Now you have a recipe for creating similar instances, as many as are needed. Functions can be used to validate blueprints and their derived instances, also, similar to Kubernetes admission control. There’s no need to build a whole new Operator or monolithic configuration generator just to automate provisioning groups of resources. Composable functions enable a low-code experience for platform builders and a no-code experience for platform users.To see this in action, check out our demo video.A GUI isn’t the only capability enabled by making the configuration in storage mutable. Nephio, the Cloud Native Network Automation project, is building on kpt, Porch, and Config Sync to fully automate configuration of interconnected network functions and the underlying infrastructure that supports those functions. Configuration as Data provides the foundational API for configuration data, enabling mutation by Nephio automation controllers.Configuration as Data is a novel approach that doesn’t sacrifice usability or the potential for higher-level automation in order to enable reproducibility. Instead, it supports an interoperable, WYSIWYG, automatable configuration authoring and editing experience. We are looking to demonstrate this innovative approach and engage with the community on advancing it further.Come innovate with usWe are looking to engage with the community to advance this technology forward. In particular, we are deeply interested in collaborating with developers working on GitOps technologies or looking to build around the existing GitOps technologies. We are including our own GitOps reference implementation Config Sync as part of kpt, but our interface to GitOps is intended to be extensible. Please check out our contact page to connect with us or jump straight to contributing. We’d love to hear and collaborate with you so that we can make GitOps usable by everyone.
Quelle: Google Cloud Platform

17. Mai 2022

da Agency

Google Cloud at KubeCon EU: New projects, updated services, and how to connect

It’s that time of the year again, when we get excited about all things cloud-native and gear up to connect, share and learn from fellow developers and technologists at KubeCon EU 2022. Here is a quick round up of the latest news from the Google open source and Kubernetes teams, and how to connect with us this week at the event. Google’s continued commitment to the open-source communityFor over 20 years, Google has helped define the state of computing with it’s commitment to open source. Google originated Kubernetes and supported the evolution of the project since contributing it to the Cloud Native Computing Foundation (CNCF) in 2015. Kubernetes became central to cloud-native computing because it was open sourced and under the governance of a neutral body. Since then, we’ve continued to invest deeply in cloud-native open source technologies on behalf of our customers. Most recently we completed the transition of Knative to the CNCF and announced our intent to contribute Istio to the organization, which alongside Kubernetes and Knative, is a critical part of cloud-native infrastructure. We continue to support the evolution of these projects and will be hosting KnativeCon at KubeCon EU, where you can learn more about the project and how you can join the community to help it grow further. Building new capabilities for critical workloads in the cloudKubernetes has been a transformative technology, bringing cloud-native best practices and design patterns to a number of industries. Yet AI/ML, batch, and HPC workloads have lagged behind traditional enterprise counterparts primarily due to the complex scheduling and resource allocation needs that make it difficult to deploy and scale these scientific workloads. Google, along with a number of community members, is working to make Kubernetes a first-class platform for these workloads through improvements to the batch API, improving scheduling performance, and leading the development of kueue, a Kubernetes-native work queue. Combined with Google Cloud’s leading hardware and autoscaling capabilities, these upstream efforts make Google Kubernetes Engine (GKE) an ideal platform for AI/ML and batch computing. To learn more about how Google is helping to add these critical capabilities into the project you can join us at Batch and HPC Day and Kubernetes AI Day onsite during KubeCon. Driving Kubernetes ease of use for customers through new open source projectsWe are embedded in open source communities, and believe in the power of the community to drive innovation and make it easier for everyone to build in the cloud. This week we reached an important milestone with a new open source offering from Google: Config Connector and Config Sync are now available as open source (Config Connector, Config Sync), joining Gatekeeper. Now, the entirety of Anthos Config Management is based on open source. We’ve also added Config Sync and the new package orchestrator to the kpt project. Together, these projects provide an end-to-end portable solution that enables a “What You See Is What You Get” configuration authoring, automation, and delivery experience, simplifies managing Kubernetes platforms and KRM-driven infrastructure at scale. We are seeking help from the community to innovate with us on this project, as we hope that it can help improve how others build platforms on top of Kubernetes. We are happy to accept contributions to kpt from the community and our customers. You can check out more information here on how to get involved as this project grows.Adding a high-usage tier to Managed Service for PrometheusThis March, we introduced Google Cloud Managed Service for Prometheus, and Kubernetes users are enthusiastic about the monitoring service’s ease of use and scalability. To get a sense of why customers are using it, you can read about the experience of Maisons du Monde, a French furniture and home decor company that adopted Managed Service for Prometheus after first running the open source version.In fact, Managed Service for Prometheus’ scalability is so strong that we’ve introduced a new high-usage tier designed for customers with extremely large volumes of metrics — more than 500 billion metric samples per month. This new pricing tier is 50% less than the previous highest-tier list price. We’ve also reduced the list price of lower-usage tiers by 25%. To get started with Managed Service for Prometheus, try out our new Managed Service for Prometheus qwiklab at no charge now through June 15, and join us on Tuesday at KubeCon for the presentation: Easy, scalable metrics for Kubernetes with Managed Service for Prometheus.The most automated and scalable managed KubernetesKubernetes is not just a technology — it’s a model for creating value for your business, a way of developing apps and services, and a means to secure and develop cloud-native IT capabilities for innovation. Given our long history with Kubernetes we are able to offer unparalleled managed services based on critical open source projects. Created by the same developers that built Kubernetes, Google Kubernetes Engine(GKE) leads the way in cloud-based Kubernetes services for running containerized applications. GKE makes it easy to recognize the benefits of innovation initiatives without getting bogged down troubleshooting infrastructure issues and managing day-to-day operations related to enterprise-scale container deployment. With fully managed Autopilot mode of operation combined with multi-dimensional auto scaling capabilities, GKE delivers most dimensions of automation to efficiently and easily operate your applications. Only GKE can run 15,000 node clusters, outscaling other cloud providers by up to 10X, letting you run applications effectively and reliably at scale.At KubeCon you will have direct access to our Kubernetes experts, starting on May 17th at our co-located event: Build with the most automated and scalable Kubernetes hosted by Google Cloud. Join us to learn what is new in the world of containers and Kubernetes here at Google Cloud and get access to technical demos.More ways to engage with Google expertise at KubeCon EUExplore several interesting courses to help get you started with Kubernetes by visiting our virtual booth. This includes some top sessions produced in the Learn Kubernetes with Googlevideo series and an opportunity to claim exclusive swag to support your Kubernetes learning from Google Cloud. You can also join over 25 sessions from Googlers onsite at the event. Kubernetes builds on more than 15 years of running Google’s containerized workloads and the invaluable contributions from the open source community. Have a question? Curious about the latest things in Google Cloud or want to talk to Kubernetes experts? Join us virtually on the CNCF slack in the #6-kubecon-googlecloud channel! There will be a number of Google Cloud and cloud-native open source community members available to field your questions. You can also request some time with our team on the ground.We are looking forward to connecting with developers and sharing expertise from some of our top Kubernetes experts this week at the event.
Quelle: Google Cloud Platform

17. Mai 2022

da Agency

Standardization, security, and governance across environments with Anthos Multi-Cloud

Kubernetes is being used for an ever growing percentage of production applications that power the world. Day 2 operations are now in focus as organizations scale from just a few clusters and applications to many clusters across multiple environments, in one cloud, multiple, and even on premise. How do you establish “sameness” across all of your clusters, regardless of where they are?Standardization, security, and governanceContainer platform teams are tasked with keeping groups of clusters up to date and aligned with their organizations standards and security policies. They will need to automate as much of this work as possible since managing 1 cluster is very different than managing 10s or 100s across geographies. Automation and keeping things as similar as possible, or sameness which is a concept Google uses internally for Kubernetes management, is critical. Anthos has a number of benefits operators can take advantage of when it comes to establishing “sameness” with regard to standardization, security, and governance across Kubernetes clusters. As a first step in evaluating Anthos it is best define the environment you will be operating in:Do you want to utilize existing Kubernetes clusters deployed with first party Kubernetes services such as Google Cloud’s GKE, Amazon’s EKS or Azure’s AKS?Are you looking to standardize on GKE across clouds for runtime consistency? This decision will define which multi-cloud product, Anthos Clusters (GKE on AWS/Azure/GCP) or Attached Clusters (any CNCF conformant K8s) are best suited to your use case when it comes to applying standardization, security, and governance across your Kubernetes estate:Standardization, security, and governance across environments Anthos Configuration Management (ACM) config sync, Policy Controller, and Service Mesh can be extended to popular Kubernetes distributions such as EKS and AKS in addition to GKE. In a multi-tenant environment you can manage the baseline configurations required across all clusters such as telemetry, infosec tooling, and networking controls centrally in your ACM git repo while allowing your teams access to namespaces for application deployment and configuration. This architecture provides a safe landing zone for applications while providing automation tooling for day 2 operations. Application teams are free to use their application deployment tool of choice within a defined namespace while the operations group manages each cluster from a centralized git repo. ACM does allow fine grained configuration syncing per cluster based on labeling schemas, which may be required if operating across environments or geographies where different tooling or policy is required.Example multi-cluster/multi-environment strategy for establishing standardization, security, and governanceUse case spotlightHosted SaaS DeploymentsDeploying microservice based software across many public cloud accounts is made possible with the Anthos Multi-Cloud API which allows standardization of your Kubernetes runtime and lifecycle management activities for the cluster and associated infrastructure across environments with centralized remote management, telemetry, and logging. Maintaining a common runtime, security posture, toolset, and observability plane across customer deployments is critical to scaling and supporting a distributed user base. These capabilities of the Anthos Multi-Cloud product have been embraced by software vendors that need to be able to provide infrastructure and application level support into their customers’ cloud environments. In the example diagram below Anthos maintains the state of each cluster in each end user account and associated GCP project. Clusters are connected to a unified CD pipeline via Config Sync. Telemetry across the cluster projects is consolidated to a custom dashboard in Google Cloud operations for a consolidated view of the entire estate.Multi-cluster/ multi-account strategy for establishing standardization, security and governance over remote applications”As an integration platform that runs on multi-clouds, we chose Anthos for multi-cloud deployments to standardize our operations across multiple clouds while relying on GKE’s valuable security and governance features which already serve us far and wide. With Anthos, we have normalized our operations and fully unified our infrastructure support.” – Diego Maia, Head of SRE, Digibee New features with Anthos 1.11 for Multi-CloudThe following multi-cloud features are part of our Anthos 1.11 Anthos Service Mesh Topology Diagrams for GKE on AWSSupport for Windows Worker NodesSupport for Dedicated Hosts/Instances for GKE on AWSApplication Logging for Linux and Windows workloadsRelated ArticleBest practices for upgrading your Anthos clusters on bare metalHere are some questions to consider before you go about upgrading your Anthos clusters running on bare metal.Read Article
Quelle: Google Cloud Platform