Migrate Graylog from virtual machines to Kubernetes

On a virtual machine, a syslog, GELF or Beats input listens on a host IP address that every sender already knows. On Kubernetes, those ports sit behind a Service, usually a load balancer or node-level exposure that you define in the chart values, so the address senders connect to changes. Every device, agent and application that writes to Graylog needs a new destination, and the port protocol must match what each input expects. Confirm the exact service type, external address and port mapping with your platform team before you touch any sender, and record the old and new endpoint for each input in the same inventory.

Protocol behavior is where cutover tests tend to fail. Syslog over UDP has no delivery acknowledgement, so a misrouted or dropped packet is silent, and a load balancer or NAT layer can change the source address Graylog records. TCP and Beats connections are stateful, so you must check how long-lived connections rebalance after a pod restarts and whether senders retry cleanly. Source IP visibility matters for stream rules and audit evidence, so send a test event from each sender type and confirm the recorded source, the input type and the message count in Graylog before you remove the old listener. Firewall rules on both sides need the same review, because the new source addresses may come from node or load balancer ranges rather than the original hosts.

Source-side changes usually take the longest part of cutover, because each change belongs to a different owner: network devices, Linux hosts running a log shipper, application teams, cloud services and security tools each need their own change window and rollback step. Build a list per device or application owner that names the sender, the input it targets, the change required, the test event to send and the person who signs off. Keep the old VM listener running until every item on that list is confirmed, and plan for some senders to be unreachable during the window.

Confirm the Kubernetes foundation before anyone installs the Graylog chart. The Graylog Helm chart requires Kubernetes v1.32 or later and Helm v3.0 or later, and it needs the MongoDB Controllers for Kubernetes Operator v1.6.1 unless you supply your own MongoDB through graylog.config.mongodb.customUri. Check the version your distribution ships against the Kubernetes releases page, because the project supports only the three most recent minor releases. Plan upgrades under the version skew policy: the API server moves first, one minor version at a time, and kubelets may lag by up to three minor versions. Since Graylog ingest runs on worker nodes, a cluster upgrade is also a log-ingest event, so schedule it against your inputs and journal capacity.

If you build the control plane yourself, treat high availability as a prerequisite, not a later improvement. The kubeadm guidance describes a stacked topology or an external etcd cluster, with at least three control plane nodes behind a TCP load balancer on port 6443. Confirm the etcd member count (odd, with five members recommended in production), that an etcd snapshot schedule exists, and that someone has rehearsed a restore. On the security side, confirm that encryption at rest is enabled for Secrets, because they are stored unencrypted in etcd by default. The Graylog chart places the MongoDB credentials and the Graylog password secret in that store, so this is not optional. Restrict list and watch access on Secrets with least-privilege RBAC, and consider an external store through the Secrets Store CSI Driver if your policy requires it. Review the CIS Kubernetes Benchmark with your platform team and map its general control areas, such as API server flags, RBAC and worker node configuration, to the cluster you will run Graylog on.

Apply Pod Security Standards to the namespace that holds Graylog, MongoDB and any collector components, and decide which level you can meet before the chart is installed. Also plan Graylog's own authentication during the move, because users will not simply carry over from virtual machines. Graylog Open supports Active Directory and LDAP as well as trusted header authentication, while Graylog Enterprise adds Okta, generic OpenID Connect and SAML single sign-on. Confirm which edition you hold, which identity provider is authoritative, and how administrator and break-glass accounts will be stored and tested before cutover. Kubernetes user authentication (client certificates, OpenID Connect or a proxy) is a separate decision for operators of the cluster, and it should be settled in the same review.

DeployOpen starts every Graylog Kubernetes migration with a written, fixed scope agreed before any work begins. The scope names each Graylog input being moved, each log source being cut over, the target cluster and namespace, the MongoDB approach (the MongoDB Controllers for Kubernetes Operator or an external URI supplied through graylog.config.mongodb.customUri), the Data Node storage design, and the acceptance tests that close each item. The first phase is an inventory of what the current virtual machines or Docker hosts actually do: which inputs listen on which ports, which streams and processing pipelines route messages, which index sets hold data and for how long, which event definitions and notifications depend on them, and which sources send to fixed addresses. Most cutover delays trace back to a source nobody listed, so this inventory is the step we treat as the basis for the quote.

The build happens inside your cluster, in your cloud account or data center, under your change control. DeployOpen plans the chart values for the official Graylog Helm chart, confirms the prerequisites in the chart README (Kubernetes v1.32 or later, Helm v3.0 or later, and the MongoDB Controllers for Kubernetes Operator v1.6.1 unless you bring your own MongoDB), and then hardens the deployment: Pod Security Standards, least-privilege RBAC, encryption at rest for Secrets, and a restricted network path from Graylog to Data Node and MongoDB. We test each input separately, including syslog, GELF and Beats where they are used, by sending known test messages, checking parsing and stream routing, and confirming the message journal drains. Cutover then moves one source group at a time, with the old host kept available until its traffic has been verified on the new endpoint.

After go-live, support is optional. Teams that want help with upgrades, cluster maintenance, testing of new inputs or ongoing operations can move to a retainer, which is priced separately from the migration scope. Before you request a quote, confirm with your platform team which Kubernetes distribution and version you will run, whether your cluster already provides a storage class and an EBS CSI driver or equivalent, and who in your organization owns the sign-off for each cutover window. Those answers change effort more than almost any other input.