<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kubernetes on Selenium</title><link>https://deploy-preview-2575--selenium-dev.netlify.app/tags/kubernetes/</link><description>Recent content in Kubernetes on Selenium</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 26 Dec 2024 13:56:22 +0700</lastBuildDate><atom:link href="https://deploy-preview-2575--selenium-dev.netlify.app/tags/kubernetes/index.xml" rel="self" type="application/rss+xml"/><item><title>Multi-Arch Images via Docker Selenium</title><link>https://deploy-preview-2575--selenium-dev.netlify.app/blog/2024/multi-arch-images-via-docker-selenium/</link><pubDate>Thu, 23 May 2024 00:00:00 +0000</pubDate><guid>https://deploy-preview-2575--selenium-dev.netlify.app/blog/2024/multi-arch-images-via-docker-selenium/</guid><description>&lt;p>We&amp;rsquo;re very happy to announce the landing of Multi-Arch Images for Selenium Grid Server on
the &lt;a href="https://hub.docker.com/r/selenium/">Selenium&lt;/a> Docker Hub registry!&lt;/p>
&lt;h3 id="motivation">Motivation&lt;/h3>
&lt;p>For experimental Docker container images that are able to run on platforms such as the Apple M-series or Raspberry Pi,
the community-driven repository initiative hosted
at &lt;a href="https://github.com/seleniumhq-community/docker-seleniarm">SeleniumHQ-Community/docker-seleniarm&lt;/a>. These images are
built for separate architectures: linux/arm64 (aarch64), linux/arm/v7 (armhf), and linux/amd64 and published
on &lt;a href="https://hub.docker.com/u/seleniarm">Seleniarm&lt;/a> Docker Hub registry.&lt;/p>
&lt;p>In order to bring more awareness to the existence of the Multi-Arch Docker container images, provide more insight and
transparency on how the container images are built, as well as overcome challenges in building and maintaining them. We
have decided to merge the fork into the main project &lt;a href="https://github.com/SeleniumHQ/docker-selenium">Docker Selenium&lt;/a>
and
published multi-arch images on &lt;a href="https://hub.docker.com/r/selenium/">Selenium&lt;/a> Docker Hub registry.&lt;/p></description></item><item><title>Scaling a Kubernetes Selenium Grid with KEDA</title><link>https://deploy-preview-2575--selenium-dev.netlify.app/blog/2022/scaling-grid-with-keda/</link><pubDate>Fri, 19 Aug 2022 00:00:00 +0000</pubDate><guid>https://deploy-preview-2575--selenium-dev.netlify.app/blog/2022/scaling-grid-with-keda/</guid><description>&lt;h2 id="the-issue">The Issue&lt;/h2>
&lt;p>If you have any experience with Selenium Grid and Kubernetes you will probably
run into an issue with scaling. Kubernetes (K8S) works wonders for scaling up and
down applications based on their CPU and Memory usage, but it is not so
straightforward when it comes down to applications like Selenium Grid.&lt;/p>
&lt;p>The issue is described quite well in &lt;a href="https://sahajamit.medium.com/spinning-up-your-own-auto-scalable-selenium-grid-in-kubernetes-part-2-15b11f228ed8">this blog post&lt;/a>.
But in short, the Horizontal Pod AutoScaler (HPA) that is built into
Kubernetes checks (by default) for resource consumption to determine
if a deployment needs to be scaled up or down. This becomes an issue
for Selenium Grid for a couple reasons:&lt;/p></description></item></channel></rss>