Adthos

adthos

Anthos on Bare Metal: How to Manage a Private Cluster From the Cloud

Lessons learned There’s a lot of buzz around Google Anthos! I’ve lost count of the number of times I’ve been asked “What IS Anthos?!”. Well today I’m NOT going to answer that question! However, what I will do is (hopefully!) help some of you to spin up your very own Anthos bite-size cluster on some relatively inexpensive hardware thanks to the newest “flavor” of Anthos: Anthos on Bare Metal. From there you’ll be able to explore the features of Anthos for yourself, and embark on your own Anthos journey of discovery! Anthos on Bare Metal allows you to spin up a cluster from as few as 2 Intel NUCs. It’s a relatively straightforward process, but the process can be a little daunting if you haven’t been through it before. I encountered a few issues along the way, so what I’m walking you through today is my “path of least resistance”! So let’s start with the hardware. I got sent 3 Intel NUCs. Each of them has a Core I7 Gen 10 processor, 32GB of RAM, and 256 GB SSD. To be more specific, here's everything that I needed to get up and running: 3x Core : 6 cores / 32GB DDR4 Mem / 256GB SSD NUC10i7FNH i7-10710U 8-port GbE switch (optional if you have enough ports on your router / switch) 4xRJ45 CAT5E 16GB USB Stick to install Ubuntu You can install Anthos on Bare Metal on Ubuntu, CoreOS, or RHEL servers. (See more details ). here Out of the box the NUCs come with Ubuntu installed. However, the Kernel version led to issues with Ansible for me, so I started from scratch and created a bootable USB stick that would install “virgin” Ubuntu 20.04 onto each NUC. I will create my cluster out of just 2 of the NUCs (which is really the minimum we’d recommend). The third I will use as my “workstation” in order to bootstrap the cluster using the command-line tool. All is not lost, however, we can add that third NUC to the cluster later, once it’s up and running! bmctl Happy-path install process Connect one of the NUCs to a monitor and keyboard. Boot it up. In the case of the NUCs I received, Ubuntu was already installed. We’ll use this machine as a workstation for now. Open a terminal & (you'll need the password for the default user) sudo su mkdir usb-boot && cd usb-boot Copy over shell script from (Thanks to my colleague Cody Hill for this!) https://github.com/c0dyhi11/ubuntu-20-04-autoinstall/blob/main/build_iso.sh chmod +x build_iso.sh Insert a USB stick into the NUC and note the device that represents the USB stick (i.e. ) fdisk -l /dev/sda (whatever is returned from above) ./build_iso.sh -F /dev/sda Ubuntu ISO will be downloaded and written to the USB stick. N.B. command will finish but writing may continue. Wait 5 mins. Powerdown your NUC. Connect your second NUC to monitor and keyboard. Insert the USB stick created in step 8. Power on. Press until the boot menu shows. Select the USB stick to boot from. If there are multiple partitions, select the first. F11 Ubuntu install will proceed. Select language, keyboard layout, network configuration (strongly recommended to switch to “manual” network config and assign a static IP). I selected not to download updates. For storage config you can just accept defaults. Do not install any other options / software / tools when prompted. You will be prompted to create a username and password. Use whatever you would like, just make a note of it. My suggestion would be to name the machine nuc-1 (and then nuc-2, and so on). At this stage you can elect to copy over an SSH key from Git if you’d like, or you can perform this step later (described in ). step 19 Wait for install / updates to fully complete (“Reboot” will show as option at bottom when it’s done). Reboot. Remove USB stick when prompted. NUC will reboot into Ubuntu. Disconnect monitor and keyboard from NUC. Repeat steps 11-14 for remaining NUC(s). Reconnect workstation NUC and boot up. Open a terminal & generate an SSH key: ssh-keygen -t rsa and copy to clipboard cat $home/.ssh/id_rsa.pub SSH into each NUC in turn (using username and password set in ) Paste in public SSH key and save Perform further steps listed here: step 12 ssh snuc@192.168.1.201 sudo su vi /root/.ssh/authorized_key Configuring Ubuntu | Anthos on bare metal From the workstation NUC validate you can SSH to each NUCvia (N.B use the path to the private SSH key you previously generated, and the IP address of each of your node NUCs). You should be able to connect to the NUC as root without being prompted for a password. ssh -o IdentitiesOnly=yes -i /home/ubuntu/.ssh/id_rsa root@ 192.168.1.231 From the workstation NUC proceed to follow instructions here: . You’ll install and init gcloud and kubectl. Next you’ll install the bmctl CLI tool. https://cloud.google.com/anthos/gke/docs/bare-metal/1.6/quickstart#install-gcloud Proceed to follow instructions here: . We’ll create a hybrid cluster - a single cluster for both admin and workloads, that can also manage user clusters.(other options are standalone, admin, & user clusters). In the hybrid cluster deployment option, one of your NUCs will be the control plane node, the other will be the worker node. You can read more about the other deployment options on . https://cloud.google.com/anthos/gke/docs/bare-metal/1.6/quickstart#create-cluster-nodes Creating clusters: overview Find a “block” of # of NUC contiguous IP addresses on your network. 3 or 4 IP addresses will be enough for the purposes of a POC. Whenever you create a K8s service of type “LoadBalancer”, one of these IP addresses will be consumed. I used 192.168.1.236-192.168.1.240. The “start” IP address (i.e. 192.168.1.236) you will specify as your ingressVIP in the YAML file. You should also find another free IP address for your controlPlaneVIP. It should NOT be in the start-end range discussed above. I used 192.168.1.196. Specify one of your NUC IP addresses as the IP address for the control plane node pool, and the other(s) right at the bottom of the YAML as the worker node pool. Run to perform preflight checks, and then to install Anthos. If you followed the instructions in step 22 then all APIs and service account keys would have been generated for you. ./bmctl create cluster -c [name of your cluster] Once it completes successfully you’ll be given the path to the kubeconfig to connect to your new cluster. [Optional] If you wish you can re-image your “workstation NUC” using the USB key, and add it as a worker node to your cluster kubectl -n my-cluster edit nodepool np1. Remember to copy your “baremetal” folder (and subfolders) off to somewhere else first (because you’ll need the kubeconfig file!). Running Your First Workload So now let’s deploy a simple “Hello world!” Kubernetes deployment and service. Let’s begin by setting our environment variable. puts the under . So, for instance, I called my cluster bm-cluster: KUBECONFIG bmctl KUBECONFIG bmctl-workspace/[your-cluster-name]/ export KUBECONFIG=$HOME/baremetal/bmctl-workspace/bm-cluster/bm-cluster-kubeconfig First let’s create a deployment YAML: apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      app: metrics
      department: sales
  replicas: template:
    metadata:
      labels:
        app: metrics
        department: sales
    spec:
      containers:
      - name: hello
        image: 3 "gcr.io/google-samples/hello-app:2.0" Save the file (as my-deployment.yaml), and now apply it to our Anthos BM cluster: kubectl apply -f my-deployment.yaml Let’s check the deployment: kubectl get deploy You should see something like this: NAME            READY   UP-TO-DATE   AVAILABLE   AGE my-deployment   3/3     3            3           30s Now let’s create a service of type LoadBalancer. Save the following YAML as my-service.yaml: apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: metrics
    department: sales
  type: LoadBalancer
  ports:
  - port: targetPort: 80 8080 Now let’s apply it: kubectl apply -f my-service.yaml Now let’s validate it got created: kubectl get svc my-service You should see something like this: Notice how my-service's IP address (external-IP) got automatically drawn from the “range” we specified earlier. Now we can curl our service, and check that everything is working as it should: For me, I , and I see: curl 192.168.1.237 Hello, world! Version: 2.0.0 Hostname: my-deployment-68bdbbb5cc-mpftc Your Anthos on BM cluster is fully operational. It will also show up in the Google Cloud console. Congratulations! If you want to log in to your cluster (to view node and workload information from the console) you can now follow the instructions on . Logging in to a cluster from Cloud Console

How to Install Anthos Bare Metal on Intel NUCs: A Beginner's Guide

The idea that you can build an app in one place and then deploy it across multiple clouds is an enticing one. That’s why multi-cloud solutions are on the rise today. They promise to help developers in expanding their cloud portfolios and battle for the industry’s attention. While Google Anthos uses a more complicated approach and you need to create a cluster for each cloud, CAST AI offers a more advanced way to solve this multi-cloud riddle - one cluster spread across multiple clouds. Google Anthos vs. CAST AI - feature comparison Google Anthos: one cluster on a single cloud, one tool for 3 clouds Anthos is Google’s new managed service offering for multi-cloud environments launched in 2019. Apart from access to multiple clouds, it offers hybrid cloud infrastructures or even a combination of on-premises and cloud-based functionalities. Anthos is a meta-service that groups Kubernetes clusters by configuration and policy. Every cluster is independent - it has its own control plane, points of ingress, deployments, and configurations. This means that developers must continuously synchronize the clusters. However, Anthos comes with cloud environments that are configured and may behave in a drastically different manner. While using Google, it offers a mostly streamlined experience. But try it on AWS or on-premises setup, and you’ll see that management is hard to automate. It requires ample knowledge of the destination cloud. CAST AI: one cluster on many clouds, unified multi-cloud for 3 clouds When you create a multi-cloud cluster with CAST AI, you get a single logical Kubernetes cluster connected across multiple cloud services. The solution creates a virtual multi-cloud private network using your VPN of choice or direct fiber connectivity between clouds. CAST AI abstracts away the differences between compute, network, ingress and load balancing, and storage. As a result, you get an open and non-proprietary Kubernetes implementation for immediate production purposes. What about cost optimization? CAST AI has a heavy focus on optimization and cost of operation. Similar to GKE, CAST provides a set of out-of-the-box auto-scalers. Scaling a CAST AI cluster is controlled through customer defined policies. The CAST AI cost optimization engine focuses on ensuring that the best possible compute instances are used for currently deployed workloads. This includes the use of spot and preemptive instances when they are available to lower overall costs. CAST AI’s multi-cloud solution does not require a special configuration management / synchronization service because of the One Cluster approach. Configurations are synchronized across clouds utilizing the underlying etcd data store that naturally supports multiple distributed master nodes. One cluster spread across multiple clouds is a more evolved approach to multi-cloud. Dealing with a single multi-cloud cluster is easier than having to constantly synchronize your clusters and only taking advantage of common configuration or policies. Explore your options and try out CAST AI Multi-cloud doesn’t have to be hard. here . We’re offering free cloud credentials to help you build your first multi-cloud clusters and play around with our infrastructure for a limited time. Just join our community on Slack. Written by Leon Kuperman Co-founder and CTO, CAST AI Formerly Vice President of Security Products OCI at Oracle, Leon’s professional experience spans across tech companies such as IBM, Truition, and HostedPCI. He founded and served as the CTO of Zenedge, an enterprise security company protecting large enterprises with a cloud WAF. Leon has 20+ years of experience in product management, software design, and development, all the way through to production deployment. He is an authority on cloud computing, web application security and Payment Card Industry Data Security Standard (PCI DSS), e-commerce, and web application architecture. Previously published at https://resources.cast.ai/blog/google-anthos-vs-cast-ai-comparison

Google Anthos Vs. Cast.AI: A Review

Recently, Google launched Anthos platform in its Cloud Next Conference and since then it has been the talk of the town! With Anthos, users can now run applications on-premise in Microsoft Azure, AWS (Amazon Web Services) and with other providers, and not just Google Cloud. It happens to be the tech giant’s official entry into the enterprise data centres. Google’s CEO Sundar Pichai says that the platform is designed with the “write once and run anywhere” notion. Let’s see what all Anthos can really do for hybrid and multi-cloud applications: What is Anthos? Anthos is a ground-breaking enterprise-grade hybrid and multi-cloud platform developed by Google. It is not a sole product, rather like an umbrella platform encompassing various micro-services and containers. These services are all about multi-cloud and hybrid cloud management, cloud migration, and so on. Anthos is an open-source platform built upon GKE that is responsible for containers service of Google Cloud. The biggest advantage of the Anthos platform is that the user won’t be limited to a specific cloud vendor. But by far, its documentation in the public cloud seems to be inadequate. How does Anthos work? Anthos allows the user to build, deploy and manage their applications with different cloud providers, all in a secure environment. It lets you modernize existing applications running on third-party clouds, whilst building and deploying cloud-native apps on containers in a multi-cloud and hybrid cloud domain. The Anthos platform provides a consistent and secure experience for the development and management of all your deployed apps. This in return also enhances developer productivity and reduces operational overhead costs. That’s because your developers or admins don’t need to study functionalities and APIs related to the new cloud, but rather just Google’s. Building Blocks of Anthos Anthos is built upon Google Kubernetes Engine (GKE) which acts as its core command and control center. GKE along with other significant components is what really makes Anthos more powerful and efficient in performance. Google Kubernetes Engine GKE lies at the core of the Anthos platform. With the GKE control panel, users can manage their entire deployed infrastructure in Google Cloud or other cloud platforms. From switching between cloud and on-premise to monitoring applications, deploying patches, and so on, GKE takes care of it all. It operates on Container-Optimized OS designed exclusively for Kubernetes. Plus, the inbuilt dashboard is where you get to manage the resources. Apart from GKE, other vital components of Anthos are as follows: GKE On-Premise The tech behemoth Google is offering a software platform based upon GKE. With GKE On-premise service, users can run this platform on any compatible hardware, while its management will be under Google’s hold. Google will handle K8s security patches and the latest version updates. Cloud Console allows you to manage your on-premise deployments and its related clusters. Know that GKE On-Premise runs as a virtual appliance on VMware vSphere 6.5 and the support for other hypervisors such as Hyper-V and KVM are still in progress. Istio Google’s Service Mesh viz. service enables fully managed service meshes to secure service communications, handle mesh telemetry, network management and other such micro-services architectures across the platform. Basically, it acts as an that brings together different components spread throughout third-party clouds, data centers and GCP. Istio Ansible Velostrata Velostrata is a P2K (material to Kubernetes) cloud migration tool developed by Google. It was built to enhance Kubernetes by converting existing VMs into Kubernetes applications as well as streaming on-premise clouds and physical machines to create clones in GCE instances. Anthos Migrate has inherited the same capabilities as in Velostrata, but it is still in beta. Anthos Config Management Users dealing with several Kubernetes deployments operating in cross-section environments will find Anthos Config Management extremely convenient. With this service, the user can apply configuration and handle various deployment clusters at the same time. Also, it allows for rapid app development across hybrid container platforms. All in all, it is a secure, well-equipped central cache for better administration and configuration. Stackdriver This service is solely dedicated to the monitoring of Anthos infrastructure as well as its applications. It acts as a core logging, tracking and monitoring system where users can keep track of different clusters throughout the Anthos. Not just that, you can also get to know the status of individual apps within each group. GCP Cloud Interconnect Cloud Interconnect is capable of clocking speed in the 100 Gbps range, which is why it can be utilized for high-speed communication between cloud frameworks and enterprise data centers. Not only that, but customers can also choose to utilize Telco networks to connect data centers to GCP. GCP (Google Cloud Platform) Marketplace GCP Marketplace enables users to deploy applications from a marketplace of open-source applications and ISVs that are Kubernetes compatible. These containerized applications are ready-to-use for quick development and deployments. Here you will find lifecycle management tools, databases and various products that can run On-premise, in clouds, on Anthos and even on other platforms involving Kubernetes clusters. Such containerized applications improve user productivity, as they can focus more on development instead of initial setups. All of these applications include solid support and maintenance services and are highly secure. GKE Hub GKE Hub is a networking component of Google Anthos. It features GCP Console through which you can integrate GKE On-premise clusters with Google Cloud Services Platform. Users can check their work-related data and Kubernetes cluster data through GKE dashboards. Google Anthos: Enterprise Ready Kubernetes seems to be a hi-tech complex platform, supposed to be managed by tech-whiz developers and admins. But Google took a step forward to discard this notion with the launch of Anthos- a platform that is enterprise-grade, secure and reliable for multi-cloud and hybrid cloud management. Make Modern Hybrid and Multi-Cloud Applications a Reality with Anthos When enterprises consider cloud migration for their workloads and applications, the first choices they turn to are Microsoft Azure and AWS. But Google Anthos is here to change the way enterprises approach the cloud migration process. This open-source cloud computing platform works across multi-cloud environments, so it is a key tool for enterprises opting for hybrid cloud deployments and application migration. Anthos is a fully-managed hybrid cloud platform that can handle application deployments across public clouds and even on-premise with consistent policies. Enterprises can modernize their existing applications, build and deploy new apps and securely run them on any platform of their choice. Due to this, developers and admins don’t need to learn different APIs and environments other than Google’s. With Anthos Migrate, organizations can also automatically migrate their VM (virtual machine) apps to GKE (Google Kubernetes Engine). These apps can be run and efficiently managed through GKE with the help of Istio service mesh component.

Making Hybrid and Multi-cloud Applications a Reality with Anthos

Google recently announced Anthos, their multi-cloud and on-prem platform offering. Anthos had its beginning on Google Cloud Platform (GCP) with as a managed Kubernetes service (Google Kubernetes Engine / GKE). As Google began expanding on their hybrid cloud strategy, GKE made its way on-prem and was rolled into Google’s Cloud Services Platform offering for hybrid cloud which eventually expanded and rebranded to Anthos. Anthos is Google’s attempt at reaching customers that have a need to be fully on-prem or haven’t taken the migration/modernization plunge out of concern of being locked into any single cloud provider. As part of the launch, Google also announced Anthos Migrate, a tool aimed at helping companies modernize their workloads in addition to migrating them. Cloud adoption is usually seen in two phases — migration followed by modernization. Cloud providers have been investing in tooling to assist customers with migration for a while now. As an example, a customer committed to migrating their business to the cloud could make use of such a migration tool (i.e. AWS SMS) to take a VM running on-prem and migrate it to run on a cloud provider (i.e. EC2). However, running on the cloud might not always be better. In the same VM migration example, let’s assume the VM was heavily over-provisioned while on-prem. Since the customer owns the host running the VM, while the host will be underutilized, the compute cost of running the VM will be fixed. When migrating the VM to a cloud provider, an administrator will likely migrate the VM to a cloud instance with similarly over-provisioned specifications. However, because the workload is over-provisioned, the customer will end up with an expensive monthly recurring bill for an underutilized instance. As such, a common activity is to rightsize and optimize workloads to be cloud-native (e.g. leverage resources efficiently for VMs in the cloud). Without this, a common problem with lift and shift migrations is the resulting low “density” deployments/utilization of computing. Part of the above problem results from VMs being very bloated runtimes for applications — in addition to the running the application, VMs also run a guest OS. Containers, on the other hand, are concise runtimes for the workloads at hand. In conjunction with a container orchestrator, containers can be optimally packed to maximize utilization of the underlying compute, resulting in “dense” deployments. Enter Anthos Migrate. Anthos Migrate assists customers in containerizing the application-only portions of their VMs. At a high level, Anthos Migrate achieves this by analyzing a VM’s disk and separating OS/system files from application and user files and containerizing the latter. In doing so, Anthos Migrate will ideally allow customers to containerize compatible workloads and realize denser deployments. It is worth noting that while Anthos Migrate will allow customers to realize denser deployments, not all VM workloads are ideal for modernization. For example, if the VM has kernel level modifications Anthos Migrate won’t work. Another aspect to note is that a complex monolith that is migrated to a container will still be a complex monolith. While a containerized complex monolith might be more cost effective for the customer, it might not realize the benefits of an application stack built from the ground up to be cloud-native (i.e. horizontally scalable, highly available, etc). Anthos Migrate will allow customers to get their foot in the door on their path to modernization and allow them to realize better compute costs for compatible workloads. However, as it is now, it is not a panacea for complete modernization as customers will still have to invest time and energy to properly modernize their workloads to be fully cloud-native. The thoughts and opinions expressed above my own and don’t necessarily represent Amazon’s position.

Anthos and what it means for app modernization

A Hitchhiker's Guide to Restaking and Its Risks

রিস্ট্যাকিং এবং এর ঝুঁকির জন্য হিচহাইকারস গাইড

Per Anhalter durch die Neuverpfändung und ihre Risiken

Una guía para autoestopistas sobre retomar y sus riesgos

Guide de l'auto-stoppeur sur le reprise et ses risques

एक सहयात्री की रीस्टेकिंग और उसके जोखिमों के बारे में मार्गदर्शिका

再ステーキングとそのリスクに関するヒッチハイカーガイド

재예약과 그 위험에 대한 히치하이커를 위한 가이드

Um guia do mochileiro para reestabelecer e seus riscos

Путешественник автостопом по пересдаче и ее рискам

Bir Otostopçunun Yeniden Seks Yapma Rehberi ve Riskleri

Hướng dẫn cho người quá giang về việc đặt lại và rủi ro của nó

搭便车者指南：重新抵押及其风险

Introduction In this article, we delve into Google Kubernetes Engine (GKE) Autopilot, an advanced managed Kubernetes service that offers an automated, hands-off experience while preserving the flexibility and power of Kubernetes. We will explore key features, setup processes, deployment strategies, and best practices for GKE Autopilot. Additionally, we will highlight some of the latest useful features of GKE and provide case studies demonstrating where GKE Autopilot can be most beneficial. Key Features of GKE Autopilot Automated Cluster and Node Management: GKE Autopilot takes care of provisioning, configuring, and scaling clusters, ensuring optimal performance at all times. This includes infrastructure, networking, and node health management, allowing teams to focus on their applications.
Advanced Networking with Managed Anthos Service Mesh: GKE Autopilot supports Managed Anthos Service Mesh, which enhances network security, observability, and traffic management using Istio’s service mesh technology. It simplifies service mesh deployment and management for a seamless experience.
Image Streaming: Available in both standard GKE and GKE Autopilot, image streaming speeds up container startup by only downloading necessary image portions, reducing latency and improving scaling efficiency.
Robust Security and Compliance: GKE Autopilot adheres to Google's best practices for securing Kubernetes environments, offering advanced security controls, secure defaults, regular updates, and integrated security tools.
Cost Optimization: With a pay-per-use model, GKE Autopilot charges only for the resources consumed by running workloads, facilitating efficient resource utilization and cost management. Setting Up GKE Autopilot Prerequisites Google Cloud Account: Ensure you have an active Google Cloud account. New users can sign up for a $300 free credit.
Google Kubernetes Engine API: Enable this API in your Google Cloud project.
Google Cloud CLI (gcloud): Install and configure the gcloud CLI. Follow the official guide for installation and initialization. Set the compute/region and compute/zone properties to avoid errors.
Permissions: Ensure your Google Cloud account has the Kubernetes Engine Cluster Admin role. Cluster Creation
To create a GKE Autopilot cluster, use the following gcloud CLI command: gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID Replace CLUSTER_NAME with your cluster name, LOCATION with the desired region (e.g., us-west1), and PROJECT_ID with your project ID. Verifying the Setup Configure kubectl: gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID Verify Cluster Mode: gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION Ensure the output includes: autopilot:
  enabled: true Check Cluster Nodes: kubectl get nodes This confirms the nodes are managed by GKE Autopilot. Deploying and Exposing Applications on GKE Autopilot Deploy applications quickly and efficiently. For example, to deploy an "Emoji Feedback" web service: kubectl create deployment emoji-feedback --image=gcr.io/google-samples/hello-app:2.0 --port=8080 --expose --type=LoadBalancer Verify the deployment and service: kubectl get deployments,services Access the service via the assigned external IP: http://<EXTERNAL-IP>:8080 Best Practices and Tips for GKE Autopilot Cost Optimization Per-Pod Pricing Model: Efficiently designed workloads can save costs since pricing is based on pod resource requests.
Committed Use Discounts: Consider these for long-term savings, especially for stable workloads.
Utilize Spot Pods: Ideal for non-critical tasks, spot pods can significantly reduce costs. Common Pitfalls and Troubleshooting Resource Allocation: Ensure accurate resource requests and limits to avoid unnecessary costs or performance issues.
Debugging Pod Issues: Check for scheduling failures or delays due to resource constraints or misconfigured network policies.
Stay Informed: Keep up with the latest GKE Autopilot updates and features. Case Studies Case Study 1: E-commerce Platform
An e-commerce company experiencing fluctuating traffic patterns benefits from GKE Autopilot’s auto-scaling and cost optimization. The platform handles high traffic during peak times while minimizing costs during off-peak periods. Case Study 2: Financial Services
A financial services firm prioritizing security and compliance utilizes GKE Autopilot’s robust security features. The automated cluster management reduces operational overhead, allowing the firm to focus on delivering secure, high-performance financial applications. Conclusion GKE Autopilot offers a serverless-like Kubernetes experience with automatic scaling, advanced security, and cost-effective resource management. By embracing its automated features, you can achieve a streamlined and powerful Kubernetes environment. Explore GKE Autopilot to enhance your Kubernetes journey and contribute to the innovation in your industry. Introduction Introduction In this article, we delve into Google Kubernetes Engine (GKE) Autopilot, an advanced managed Kubernetes service that offers an automated, hands-off experience while preserving the flexibility and power of Kubernetes. We will explore key features, setup processes, deployment strategies, and best practices for GKE Autopilot. Additionally, we will highlight some of the latest useful features of GKE and provide case studies demonstrating where GKE Autopilot can be most beneficial. Key Features of GKE Autopilot Key Features of GKE Autopilot Automated Cluster and Node Management: GKE Autopilot takes care of provisioning, configuring, and scaling clusters, ensuring optimal performance at all times. This includes infrastructure, networking, and node health management, allowing teams to focus on their applications. Advanced Networking with Managed Anthos Service Mesh: GKE Autopilot supports Managed Anthos Service Mesh, which enhances network security, observability, and traffic management using Istio’s service mesh technology. It simplifies service mesh deployment and management for a seamless experience. Image Streaming: Available in both standard GKE and GKE Autopilot, image streaming speeds up container startup by only downloading necessary image portions, reducing latency and improving scaling efficiency. Robust Security and Compliance: GKE Autopilot adheres to Google's best practices for securing Kubernetes environments, offering advanced security controls, secure defaults, regular updates, and integrated security tools. Cost Optimization: With a pay-per-use model, GKE Autopilot charges only for the resources consumed by running workloads, facilitating efficient resource utilization and cost management. Automated Cluster and Node Management : GKE Autopilot takes care of provisioning, configuring, and scaling clusters, ensuring optimal performance at all times. This includes infrastructure, networking, and node health management, allowing teams to focus on their applications. Automated Cluster and Node Management Advanced Networking with Managed Anthos Service Mesh : GKE Autopilot supports Managed Anthos Service Mesh, which enhances network security, observability, and traffic management using Istio’s service mesh technology. It simplifies service mesh deployment and management for a seamless experience. Advanced Networking with Managed Anthos Service Mesh Image Streaming : Available in both standard GKE and GKE Autopilot, image streaming speeds up container startup by only downloading necessary image portions, reducing latency and improving scaling efficiency. Image Streaming Robust Security and Compliance : GKE Autopilot adheres to Google's best practices for securing Kubernetes environments, offering advanced security controls, secure defaults, regular updates, and integrated security tools. Robust Security and Compliance Cost Optimization : With a pay-per-use model, GKE Autopilot charges only for the resources consumed by running workloads, facilitating efficient resource utilization and cost management. Cost Optimization Setting Up GKE Autopilot Setting Up GKE Autopilot Prerequisites Prerequisites Google Cloud Account: Ensure you have an active Google Cloud account. New users can sign up for a $300 free credit. Google Kubernetes Engine API: Enable this API in your Google Cloud project. Google Cloud CLI (gcloud): Install and configure the gcloud CLI. Follow the official guide for installation and initialization. Set the compute/region and compute/zone properties to avoid errors. Permissions: Ensure your Google Cloud account has the Kubernetes Engine Cluster Admin role. Google Cloud Account : Ensure you have an active Google Cloud account. New users can sign up for a $300 free credit. Google Cloud Account Google Kubernetes Engine API : Enable this API in your Google Cloud project. Google Kubernetes Engine API Google Cloud CLI (gcloud) : Install and configure the gcloud CLI. Follow the official guide for installation and initialization. Set the compute/region and compute/zone properties to avoid errors. Google Cloud CLI (gcloud) Permissions : Ensure your Google Cloud account has the Kubernetes Engine Cluster Admin role. Permissions Cluster Creation To create a GKE Autopilot cluster, use the following gcloud CLI command: Cluster Creation gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID Replace CLUSTER_NAME with your cluster name, LOCATION with the desired region (e.g., us-west1), and PROJECT_ID with your project ID. CLUSTER_NAME LOCATION PROJECT_ID Verifying the Setup Verifying the Setup Configure kubectl: Configure kubectl : Configure kubectl gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID Verify Cluster Mode: Verify Cluster Mode : Verify Cluster Mode gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION Ensure the output includes: autopilot:
  enabled: true autopilot:
  enabled: true Check Cluster Nodes: Check Cluster Nodes : Check Cluster Nodes kubectl get nodes kubectl get nodes This confirms the nodes are managed by GKE Autopilot. Deploying and Exposing Applications on GKE Autopilot Deploying and Exposing Applications on GKE Autopilot Deploy applications quickly and efficiently. For example, to deploy an "Emoji Feedback" web service: kubectl create deployment emoji-feedback --image=gcr.io/google-samples/hello-app:2.0 --port=8080 --expose --type=LoadBalancer kubectl create deployment emoji-feedback --image=gcr.io/google-samples/hello-app:2.0 --port=8080 --expose --type=LoadBalancer Verify the deployment and service: kubectl get deployments,services kubectl get deployments,services Access the service via the assigned external IP: http://<EXTERNAL-IP>:8080 http://<EXTERNAL-IP>:8080 Best Practices and Tips for GKE Autopilot Best Practices and Tips for GKE Autopilot Cost Optimization Cost Optimization Per-Pod Pricing Model: Efficiently designed workloads can save costs since pricing is based on pod resource requests. Committed Use Discounts: Consider these for long-term savings, especially for stable workloads. Utilize Spot Pods: Ideal for non-critical tasks, spot pods can significantly reduce costs. Per-Pod Pricing Model : Efficiently designed workloads can save costs since pricing is based on pod resource requests. Per-Pod Pricing Model Committed Use Discounts : Consider these for long-term savings, especially for stable workloads. Committed Use Discounts Utilize Spot Pods : Ideal for non-critical tasks, spot pods can significantly reduce costs. Utilize Spot Pods Common Pitfalls and Troubleshooting Common Pitfalls and Troubleshooting Resource Allocation: Ensure accurate resource requests and limits to avoid unnecessary costs or performance issues. Debugging Pod Issues: Check for scheduling failures or delays due to resource constraints or misconfigured network policies. Stay Informed: Keep up with the latest GKE Autopilot updates and features. Resource Allocation : Ensure accurate resource requests and limits to avoid unnecessary costs or performance issues. Resource Allocation Debugging Pod Issues : Check for scheduling failures or delays due to resource constraints or misconfigured network policies. Debugging Pod Issues Stay Informed : Keep up with the latest GKE Autopilot updates and features. Stay Informed Case Studies Case Studies Case Study 1: E-commerce Platform An e-commerce company experiencing fluctuating traffic patterns benefits from GKE Autopilot’s auto-scaling and cost optimization. The platform handles high traffic during peak times while minimizing costs during off-peak periods. Case Study 1: E-commerce Platform Case Study 2: Financial Services A financial services firm prioritizing security and compliance utilizes GKE Autopilot’s robust security features. The automated cluster management reduces operational overhead, allowing the firm to focus on delivering secure, high-performance financial applications. Case Study 2: Financial Services Conclusion Conclusion GKE Autopilot offers a serverless-like Kubernetes experience with automatic scaling, advanced security, and cost-effective resource management. By embracing its automated features, you can achieve a streamlined and powerful Kubernetes environment. Explore GKE Autopilot to enhance your Kubernetes journey and contribute to the innovation in your industry.

Elevating Kubernetes Operations: The Professional's Guide to GKE Autopilot

When we first came up with our “big idea” back in 2017, my partner Mike Wagner and I didn’t know how much impact it would have. The idea was simple enough: We wanted to develop a virtual appliance that could discover, provision, and maintain servers from any manufacturer. By 2020, that vision became a reality with the launch of our flagship platform, which we built entirely on open-source technologies. That strategy was working well from the start. Well enough, I should say. We knew we could improve our metal-as-a-service software appliance if we could just find a way to boost performance, ensure higher system uptime, and streamline the architecture. The only way to do that, we realized, was to replace the Linux operating system and KVM virtual machine solution with something that would give us those benefits. What we did know was that we wanted to continue with our strategy of utilizing open source—and ideally tied to a very permissive license and open governance model. That would give us more flexibility as our roadmap unfolded and enable extensive use and modification without stringent (or murky) conditions. Taking the plunge After our due diligence, we transitioned to the Unix-like open source FreeBSD operating system, along with the BSD hypervisor Bhyve. We liked that the FreeBSD project had off-the-shelf capabilities within a single distribution, and had plenty of mission-critical enterprise use cases (Netflix and Sony being two of the most well-known). Together with existing technologies like the Redfish standard, the new and improved platform we’d built (called Mojo) was ready to really take off. With FreeBSD and bhyve fully in place, we were now able to add edge data center provisioning to the platform, which helps discover, configure, and provision bare metal servers and storage within a data center and at the edge. It works really well with another new technology (PhotoISP, which I’ll discuss in a moment) to manage geographically distributed bare metal assets. These open-source changes to our infrastructure proved to be the silver bullet we were looking for. More organizations began to contact us, and we started landing some really interesting use cases, including Major League Baseball. Before the 2021 season, MLB was looking for a way to move from VMware to a containerized environment across 30 data centers. In a nutshell, they needed a way to quickly process 15 different input sources to track all the player and team statistics generated during a game. By more quickly provisioning servers, that data could be quickly gathered at the edge and uploaded into Google Cloud. The Mojo platform, backed by an evolved open-source strategy, helped streamline MLB’s deployment pipelines (cutting deployment time in half). It also simplified the provisioning and management of MLB’s bare metal edge sites and made it really easy to provision Anthos, BIOS, firmware, OS patches, and upgrades. They also saw big performance gains for their GPU-enabled apps and more optimized CI/CD pipelines. Expanding a vision backed by open source Albert Einstein once said that necessity is the mother of all invention. My family lives in the Blue Ridge Mountains, and when COVID hit, word spread quickly that several teachers and students were unable to stream their classes because they had insufficient rural broadband access. Mike and I brainstormed about how we could help, and we immediately recognized how Mojo, paired with a reliable and secure CPE, could solve the problem. That led development of the Photon ISP platform, which delivers routing, firewall, and QoS through the open-source FreeBSD operating system. It also monitors IDS/IPS for wireless and fixed fiber networks and ensures uninterrupted 4G/5G and Starlink failover as a hedge to wireless ISP services. Today, the Photon ISP platform has 50 rural customers, and that number continues to grow. And its uptime is unparalleled; we have FreeBSD CPEs that have been running for more than a year without issue. Speeds have been very consistent, streaming content has been reliable, and there has been almost zero latency. We’re still pushing the limits of what we can do with our optimized open-source infrastructure. Next, we plan to finish moving the remainder of the stack to FreeBSD once a viable OCI-compliant stack becomes available. In the meantime, we still use Linux within Bhyve virtual machines for a few of our services. Simply put, the strategic shift to open-source FreeBSD and Bhyve for our platforms has catalyzed innovation and customer growth. The success with MLB—cutting deployment times and improving performance—is a great example of how the right open-source pieces can have an outsized impact while being far more flexible (not to mention cost-efficient!) than proprietary alternatives. When we first came up with our “big idea” back in 2017, my partner Mike Wagner and I didn’t know how much impact it would have. The idea was simple enough: We wanted to develop a virtual appliance that could discover, provision, and maintain servers from any manufacturer. By 2020, that vision became a reality with the launch of our flagship platform, which we built entirely on open-source technologies. That strategy was working well from the start. Well enough , I should say. enough We knew we could improve our metal-as-a-service software appliance if we could just find a way to boost performance, ensure higher system uptime, and streamline the architecture. The only way to do that, we realized, was to replace the Linux operating system and KVM virtual machine solution with something that would give us those benefits. What we did know was that we wanted to continue with our strategy of utilizing open source—and ideally tied to a very permissive license and open governance model. That would give us more flexibility as our roadmap unfolded and enable extensive use and modification without stringent (or murky) conditions. Taking the plunge After our due diligence, we transitioned to the Unix-like open source FreeBSD operating system, along with the BSD hypervisor Bhyve . We liked that the FreeBSD project had off-the-shelf capabilities within a single distribution, and had plenty of mission-critical enterprise use cases (Netflix and Sony being two of the most well-known). Together with existing technologies like the Redfish standard, the new and improved platform we’d built (called Mojo) was ready to really take off. open source FreeBSD Bhyve Redfish With FreeBSD and bhyve fully in place, we were now able to add edge data center provisioning to the platform, which helps discover, configure, and provision bare metal servers and storage within a data center and at the edge. It works really well with another new technology (PhotoISP, which I’ll discuss in a moment) to manage geographically distributed bare metal assets. These open-source changes to our infrastructure proved to be the silver bullet we were looking for. More organizations began to contact us, and we started landing some really interesting use cases, including Major League Baseball. Before the 2021 season, MLB was looking for a way to move from VMware to a containerized environment across 30 data centers. In a nutshell, they needed a way to quickly process 15 different input sources to track all the player and team statistics generated during a game. By more quickly provisioning servers, that data could be quickly gathered at the edge and uploaded into Google Cloud. The Mojo platform, backed by an evolved open-source strategy, helped streamline MLB’s deployment pipelines (cutting deployment time in half). It also simplified the provisioning and management of MLB’s bare metal edge sites and made it really easy to provision Anthos, BIOS, firmware, OS patches, and upgrades. They also saw big performance gains for their GPU-enabled apps and more optimized CI/CD pipelines. Expanding a vision backed by open source Albert Einstein once said that necessity is the mother of all invention. My family lives in the Blue Ridge Mountains, and when COVID hit, word spread quickly that several teachers and students were unable to stream their classes because they had insufficient rural broadband access. Mike and I brainstormed about how we could help, and we immediately recognized how Mojo, paired with a reliable and secure CPE, could solve the problem. That led development of the Photon ISP platform, which delivers routing, firewall, and QoS through the open-source FreeBSD operating system. It also monitors IDS/IPS for wireless and fixed fiber networks and ensures uninterrupted 4G/5G and Starlink failover as a hedge to wireless ISP services. Today, the Photon ISP platform has 50 rural customers, and that number continues to grow. And its uptime is unparalleled; we have FreeBSD CPEs that have been running for more than a year without issue. Speeds have been very consistent, streaming content has been reliable, and there has been almost zero latency. We’re still pushing the limits of what we can do with our optimized open-source infrastructure. Next, we plan to finish moving the remainder of the stack to FreeBSD once a viable OCI-compliant stack becomes available. In the meantime, we still use Linux within Bhyve virtual machines for a few of our services. Simply put, the strategic shift to open-source FreeBSD and Bhyve for our platforms has catalyzed innovation and customer growth. The success with MLB—cutting deployment times and improving performance—is a great example of how the right open-source pieces can have an outsized impact while being far more flexible (not to mention cost-efficient!) than proprietary alternatives.

How Our Open Source OS Pivot Accelerated Product Innovation

376 Stories To Learn About Google

I found that an order had already gone forth for the army to proceed immediately towards Constantino

Stories, News & Mentions about ADTHOS

Adthos’s Stories on HackerNoon