AKS Welcomes you to Ignite 2023
Hi everyone, and welcome to Microsoft Ignite 2023! The AKS team is looking forward to connecting in person and virtually with all the AKS community, throughout the Ignite Keynotes, Breakouts, QA sessions, expert meetups or over a beverage in the hallways! The team has been hard at work making Azure the best platform to run Kubernetes and a truly Kubernetes-powered cloud. And over the last year Microsoft continued to leverage AKS as a tried and test platform for its critical workloads, putting a healthy amount of pressure on the service and continuing to help us push the boundaries of what’s possible with cloud native platforms and intelligent apps. As Kubernetes continues to become pervasive, a lot of teams find themselves at different steps of their adoption, skillset or learning stage. At Build 2023 we showed a prototype of an assistant for AKS that would make the perfect companion for any everyday task with AKS and Kubernetes. As part of our private preview, a lot of our users told us how great it would be if they could have that for all of Azure and today, we're happy to announce that all of those capabilities and more have been rolled into the new Microsoft Copilot for Azure. This AI companion will help you design, operate, optimize and troubleshoot any service and brings every integration we showed for AKS and much more, including new handlers for log collection or permissions validation. The Microsoft Copilot for Azure will be the perfect assistant for all teams at any stage of their AKS and cloud adoption journey! Sign up for the preview here! Improving resilience and uptime with simplified global footprint Nowadays, all industries, companies and solutions rely in one way or another on software and digital components, and more than ever users expect flawless services that never fail performing at a high level. This has increased a lot of the resiliency requirements of most of our existing and new users. One of the most common ways to increase availability and resilience is ensuring a global footprint across multiple regions and geographies, with the added value that you can serve your users closer to their locations while benefiting from protection in case anything goes wrong with one of the regions. However, this could increase the complexity of management and operations of multiple clusters across these regions, so we’re thrilled to announce that Azure Kubernetes Fleet Manager is now Generally Available, allowing you to create fleets of AKS clusters with a few clicks and easily distribute workloads across them while orchestrating operations like upgrades across them in a consistent manner. Fleet Manager is also very modular, allowing you to use exactly the functionality you want without requiring you to change your practices for scenarios you already solved for today. You can choose to use it with a hub (a fully managed hub cluster that controls things like namespace and workload placement without requiring any management) or hubless if you just want a central view of clusters and central management of operations like upgrades. As we wrapped KubeCon North America last week, 2 trends became very apparent as we talked with users and the community. The first one is how Kubernetes is uniquely positioned to power the AI revolution, providing a scalable, reliable and extensible platform that can meet the ever-changing needs of our users. The second was around the continued need for better cost visualization and optimization and more streamlined operations in order to reduce costs from all angles and allow users and business to focus on creating value for their business. These trends have long resonated with the team and we’re happy to show some of the latest things we’ve been working on in these areas. Kubernetes powering the AI revolution Today you can already use kubernetes in conjunction with some of Azure’s great AI services in order to very quickly and efficiently create intelligent applications that can scale and sustain any demand. However, many scenarios with privacy or customization requirements, for example, might need you to run/host your own model and customized inferencing. This brings a lot of challenges as you need to figure out how to containerize the models, host them, find capacity and the right GPUs for them, schedule them, provide endpoints so your apps can plug into them, etc. So to simplify this we’re happy to announce the AI Toolchain Operator addon for AKS, based on the open source KAITO project. This addon will drastically simplify the experience and number of steps to run an OSS model from dozens and many days/weeks of work, to just a couple steps and a few minutes. It will also assist you setting up an endpoint for your applications to consume so you can quickly integrate with new or existing apps. We’re looking forward to partnering with our existing preview customers and now with all users to continue to simplify and enrich this experience and provide further integrations with the Azure ecosystem. One of the key tenets of responsible AI is ensuring privacy concerns are addressed and respected. A few months ago, we demonstrated a prototype for Confidential Containers allowing you to run any workload leveraging confidential hardware capabilities without any code changes and we’re happy to announce that Kata Confidential Containers are now in public preview. Another important aspect is ensuring the provenance of your images to ensure that your supply chain doesn’t suffer from any tampering, so last month AKS announced Image Integrity, which allows you to sign any container image in ACR and validate its signature via policy on an AKS cluster, leveraging the Ratify open-source project. Visualize, reduce costs & streamline operations In our wider conjuncture, it’s of the utmost importance to ensure that teams’ infrastructure and operations are as efficient as possible and allow them to focus on their business outcomes. We’ve been focusing on 3 main areas: Cost Visualization: We’re announcing the cost analysis addon that allows direct integration of namespace and kubernetes assets billing with the Azure Cost Management portal. All of which builds on top of the open-source OpenCost project. Efficient scaling and cost reduction: For pod level scaling we’re very happy to announce the General Availability of KEDA (Kubernetes Event Driven Autoscaler) addon. For the infrastructure, one of the key pain points is knowing the best, cheapest and most readily available SKUs as well as ensure the most efficient usage of nodes by tightly binpacking pods/containers within them. So we’re very happy to be able to announce the Node Auto Provision addon, which leverage the open source Karpenter project to efficiently select the cheapest, highly available and most suited VM SKUs that allow for the most efficient bin-packing of your environments. Lighting fast and efficient container starts: We’re announcing Artifact Streaming for Linux, allowing faster image pulls/container starts of at least 15% (with many cases well over 50%) prioritizing the pull of the essential layers and using the containerd overlaybd project. System reserved optimization: The team has worked hard on optimizing the resource usage of the kubernetes system components, allowing that every node after Kubernetes 1.28 (now GA) will have 20% more allocatable space for workloads. Simplifying common operations: We’ve provided over 10 new enhancements for Virtual nodes allowing for many more bursting and serverless scenarios to be possible, from LB services integration, container probes, debug containers and exec/port-forward capabilities, bringing a lot more parity to native node capabilities to this option. Additionally, for one of the most common tasks for applications, setting up routing (ingress, DNS, certificates), we’re making the Application Routing addon generally available, so you can have a fully managed and scalable bundle of all those capabilities delivered out of the box by AKS. The are some of the latest things the teams have been working on, with many more available on the AKS Release Notes and throughout our announcements. We can’t wait to meet you and chat about these or many other of our announcements and discuss what’s coming next and how we can help you achieve even more. Make sure to follow our roadmap for what’s coming and the AKS community for deep dive content on AKS.Reference Architecture for a High Scale Moodle Environment on Azure
Introduction Moodle is an open-source learning platform that was developed in 1999 by Martin Dougiamas, a computer scientist and educator from Australia. Moodle stands for Modular Object-Oriented Dynamic Learning Environment, and it is written in PHP, a popular web programming language. Moodle aims to provide educators and learners with a flexible and customizable online environment for teaching and learning, where they can create and access courses, activities, resources, and assessments. Moodle also supports collaboration, communication, and feedback among users, as well as various plugins and integrations with other systems and tools. Moodle is widely used around the world by schools, universities, businesses, and other organizations, with over 100 million registered users and 250,000 registered sites as of 2020. Moodle is also supported by a large and active community of developers, educators, and users, who contribute to its development, documentation, translation, and support. [URL] is the official website of the Moodle project, where anyone can download the software, join the forums, access the documentation, participate in events, and find out more about Moodle. Goal The goal for this architecture is to have a Moodle environment that can handle 400k concurrent users and scale in and out its application resources according to usage. Using Azure managed services to minimize operational burden was a design premise because standard Moodle reference architectures are based on Virtual Machines that comes with a heavy operational cost. Challenges Being a monolith application, scaling Moodle in a modern cloud native environment is challenging. We choose to use Kubernetes as its computing provider due to the fact that it allow us to build a Moodle artifact in an immutable way that allows it to scale out and in when needed in a fast and automatic way and also recover from potential failures by simply recreating its Deployments without the need to maintain Virtual Machine resources, introducing the concept of pets vs cattle[1] to a scenario that at first glance wouldn't be feasible. Since Moodle is written in PHP it has no concept of database polling, creating a scenario where its underlying database is heavily impacted by new client requests, making it necessary to use an external database pooling solution that had to be custom tailored in order to handle the amount of connections for a heavy-traffic setup like this instead of using Azure Database for PostgreSQL's built-in pgbouncer. The same effect is also observed in its Redis implementation, where a custom Redis cluster had to be created, whereas using Azure Cache for Redis would incur prohibitive costs due to the way it is set up for a more general usage. 1 - https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/definition#the-cloud Architecture This architecture uses Azure managed (PaaS) components to minimize operational burden by using Azure Kubernetes Service to run Moodle, Azure Storage Account to host course content, Azure Database for PostgreSQL Flexible Server as its database and Azure Front Door to expose the application to the public as well as caching commonly used assets. The solution also leverages Azure Availability Zones to distribute its component across different zones in the region to optimize its availability. Provisioning the solution The provisioning has two parts: setting up the infrastructure and the application. The first part uses Terraform to deploy easily. The second part involves creating Moodle's database and configuring the application for optimal performance based on the templates, number of users, etc. and installing templates, courses, plugins etc. The following steps walk you through all tasks needed to have this job done. Clone the repository $ git clone https://github.com/Azure-Samples/moodle-high-scale Provision the infrastructure $ cd infra/ $ az login $ az group create --name moodle-high-scale --location <region> $ terraform init $ terraform plan -var moodle-environment=production $ terraform apply -var moodle-environment=production $ az aks get-credentials --name moodle-high-scale --resource-group moodle-high-scale Provision the Redis Cluster $ cd ../manifests/redis-cluster $ kubectl apply -f redis-configmap.yaml $ kubectl apply -f redis-cluster.yaml $ kubectl apply -f redis-service.yaml Wait for all the replicas to be running $ ./init.sh Type 'yes' when prompted. Deploy Moodle and its services Change image in moodle-service.yaml and also adjust the moodle data storage account name in the nfs-pv.yaml (see commented lines in the files) $ cd ../../images/moodle $ az acr build --registry moodlehighscale<suffix> -t moodle:v0.1 --file Dockerfile . $ cd ../../manifests $ kubectl apply -f pgbouncer-deployment.yaml $ kubectl apply -f nfs-pv.yaml $ kubectl apply -f nfs-pvc.yaml $ kubectl apply -f moodle-service.yaml $ kubectl -n moodle get svc –watch Provision the frontend configuration that will be used to expose Moodle and its assets publicly $ cd ../frontend $ terraform init $ terraform plan $ terraform apply Approve the private endpoint connection request from Frontdoor in moodle-svc-pls resource. Private Link Services > moodle-svc-pls > Private Endpoint Connections > Select the request from Front Door and click on Approve. Install database $ kubectl -n moodle exec -it deployment/moodle-deployment -- /bin/bash $ php /var/www/html/admin/cli/install_database.php --adminuser=admin_user --adminpass=admin_pass --agree-license Deploy Moodle Cron Change image in moodle-cron.yaml $ cd ../manifests $ kubectl apply -f moodle-cron.yaml Your Moodle installation is now ready to use! Conclusion You can create a Moodle environment that is scalable and reliable in minutes with a very simple approach, without having to deal with the hassle of operating its parts that normally comes with standard Moodle installations.Azure Kubernetes Service Baseline - The Hard Way
Are you ready to tackle Kubernetes on Azure like a pro? Embark on the “AKS Baseline - The Hard Way” and prepare for a journey that’s likely to be a mix of command line, detective work and revelations. This is a serious endeavour that will equip you with deep insights and substantial knowledge. As you navigate through the intricacies of Azure, you’ll not only face challenges but also accumulate a wealth of learning that will sharpen your skills and broaden your understanding of cloud infrastructure. Get set for an enriching experience that’s all about mastering the ins and outs of Azure Kubernetes Service!Azure Kubernetes upgrades and Long Term Support
Microsoft has long invested in the upstream Kubernetes community, and as our Azure team members have led and participated in the Kubernetes release process, we’ve listened to what our customers say about the pace of Kubernetes development. Today we are excited to announce the introduction of Azure Kubernetes Service (AKS) Long Term Support (LTS). We’re hearing from customers across a variety of organizations, from healthcare to manufacturing and beyond, who need a longer window of stability. We’ve heard from ISVs that having to be on a constant treadmill to keep their environments in sync with community releases adds a significant burden to delivering value to their customers. For organizations with multiple teams or complex environments, staying on top of upgrades can pose a significant challenge. With three releases happening each year and a year of support for any given release, updates require frequent action. LTS will help teams plan and test upgrades on a longer timeline, while staying on a supported Kubernetes version. It is critically important for all Kubernetes users that when they choose to run their applications on versions of Kubernetes that are not maintained by the community that the entire stack from the operating system to the Kubernetes components are maintained and patched by their service provider. The only way to host your applications on a Kubernetes version that is out of community support is to either run without security updates, or to put significant effort into forking the version, and cherry picking or resolving security issues yourself. Based on feedback from our customers, we decided to put a team together to do just that. We will be forking and maintaining the Kubernetes codebase for the LTS version once it leaves community support and maintaining this in the open. The first AKS version that can have Long Term Support will be 1.27, to be released in May 2023. While running a cluster at an LTS version, customers will receive support and security updates for two years from the GA date (instead of the usual one year). We intend to restart the community’s kubernetes WG-LTS to collaborate across the ecosystem to collect requirements and define processes and tooling required for creating secure and stable long term support releases of Kubernetes in the future. https://github.com/aks-lts is a work in progress, and we welcome feedback and contributions. Customers will be able to opt in to LTS support for Kubernetes 1.27 at any time, or spin up Kubernetes 1.27 clusters and node pools during that two year period. Making upgrades simple and safe Upgrading with confidence requires an understanding of how any change will affect your continuity of cluster operations. AKS supports fully automated in-place cluster upgrades (controlled via upgrade schedules) or manual in case you need more control over when these happen. In order to make the upgrade process for Kubernetes minor versions easier, the objects in ETCD are automatically converted to the newer APIs. And now AKS will detect if you are using a deprecated API anywhere (for example operators or your code), and we will prevent the upgrade, and warn you in order to stop you from inadvertently breaking your applications. You can override to force the upgrade or correct the API usage and retry after a period of time. You decide when to move from one Kubernetes version to another, allowing you to plan and test your migrations. For non-LTS clusters, each Kubernetes version is supported for 12 months. After 12 months, the minor version will shift to platform support only. Our new platform support policy provides customers with Azure infrastructure support while the cluster is in an n-3 version (where n is the latest supported AKS GA minor version). Platform support does not include anything related to Kubernetes functionality and components, but provides customers with additional support beyond what was previously provided for unsupported versions. AKS will make the automatic upgrade of out of support clusters predictable to ensure they remain within a Kubernetes supported version. When a cluster in an n-3 version is about to drop to n-4, AKS will automatically upgrade the cluster to n-2. For example, Kubernetes v1.25 will be upgraded to v1.26 during the v1.29 GA release. For more information, see the AKS documentation. We always recommend our customers stay within community support, and whether your needs are best served by an LTS Kubernetes release or an automatically upgraded cluster, Azure's support commitment to you is the same. Instead of a constant race to keep up with an ever-changing API surface while worrying about unpatched CVEs, Azure Kubernetes Service customers can grow their cloud native estates in confidence of their support and continuity. For more information on Kubernetes version support on AKS, assess your options, and for pricing information, take a look at the Supported Kubernetes section on Azure Docs.Preview support for Kata VM Isolated Containers on AKS for Pod Sandboxing
The rise of cloud-native and shift to containerized workloads has revolutionized the velocity of application development and drastically improved the ease of deployment when building applications. While these technologies provide many benefits, they also present a security risk when the shared kernel and the container host are exposed to untrusted malicious container code. One way to mitigate this risk is by running each pod/container in a dedicated, lightweight VM with resources like compute, memory, networking carved out from the parent VM on a dedicated kernel. This is known as Pod Sandboxing. Pod Sandboxing allows you to continue to co-locate pods on the same host but adds a layer of isolation to help mitigate shared kernel attacks and reduce risks from escaped containers when running in a shared agent node.Azure Kubernetes Service Microsoft Ignite announcements
When we talk to Azure Kubernetes Service (AKS) customers about the adoption of Kubernetes, two focus areas come up just about every time: the challenges of running at scale and the ongoing desire to improve their security posture. At Microsoft Ignite 2022, we announced a number of new features for AKS to help you operate your Kubernetes clusters and workloads at the scale you need, and we’ve continued to innovate in the open to improve the security posture and landscape, providing a seamless, and secure platform for your applications.
