

Vereisten
Om deze alternatieve aanpak te implementeren, zijn er een paar vereisten waaraan voldaan moet worden:
- Je moet de container inzetten in een Kubernetes cluster.
- De applicatie moet het toevoegen van JVM-parameters via een omgevingsvariabele ondersteunen.
Startpunt
Laten we aannemen dat je applicatie een StatefulSet gebruikt die er ongeveer zo uitziet:

De naam van de JAVA_OPTS omgevingsvariabele kan variëren afhankelijk van de specifieke applicatie.
De New Relic agent jar verpakken
Om het implementatieproces te vereenvoudigen, maken we een aangepast image dat de New Relic agent jar bevat. Om dit image te maken, gebruiken we een Container File, die er ongeveer zo uit kan zien:

De New Relic agent "injecteren" in de applicatiecontainer
Om de applicatie de New Relic agent jar te laten gebruiken, maken we gebruik van de concepten Kubernetes Init Container en emptyDir.
De resulterende StatefulSet ziet er als volgt uit:

In plaats van de New Relic agent jar in de applicatie-image op te nemen, gebruiken we onze aangepaste newrelic-agent image als een Init Container. Deze container kopieert het newrelic.jar bestand naar een emptyDir volume.
Aangezien de Init Container vóór de gewone applicatiecontainer draait en beide hetzelfde volume delen, is het newrelic.jar-bestand toegankelijk wanneer de JVM start.
Afgezien van het gedeelde volume, hebben we een paar New Relic agent-specifieke omgevingsvariabelen nodig:
- NEW_RELIC_APP_NAME: om de applicatienaam in te stellen
- NEW_RELIC_LICENSE_KEY: om de licentiesleutel op te geven
- NEW_RELIC_LOG_FILE_NAME: om optioneel een niet-standaard log locatie in te stellen, in dit geval STDOUT.
Er zijn een paar extra omgevingsvariabelen beschikbaar in de New Relic Java agent documentatie die gebruikt kunnen worden.
Naast deze basisconfiguratie kun je ook de configuratie van de New Relic server-side agent gebruiken.
Zoals je kunt zien in de JAVA_OPTS omgevingsvariabele, moeten we nog steeds de JVM instrueren om de New Relic agent jar te gebruiken. Het is de moeite waard om te vermelden dat dit specifieke bestand zich op het gedeelde volume bevindt.
Let ook op de "imagePullPolicy" die we hebben ingesteld op "Always" om ervoor te zorgen dat we altijd de laatste image-versie ophalen, zelfs als deze nog steeds dezelfde tag gebruikt.
De New Relic agent bijwerken
Om ervoor te zorgen dat de New Relic agent altijd up-to-date is, kun je een Continuous Integration pipeline opzetten die automatisch een nieuwe container image bouwt wanneer er een nieuwe agent versie beschikbaar komt.
Daarnaast kun je de image taggen met major, major.minor, en major.minor.patch, naast "latest". Hierdoor kun je de agentversie vastpinnen op basis van de specifieke vereisten van je toepassing.
Afhankelijk van de image tag die gespecificeerd is in het manifest bestand van de applicatie, kan het updaten net zo eenvoudig zijn als het herstarten van de applicatie pods.
Als je er de voorkeur aan geeft om de New Relic agent vast te zetten op een specifieke versie, moet je de newrelic-agent image tag in de StatefulSet bijwerken en deze wijziging implementeren in je Kubernetes cluster.
In ieder geval hoef je niet langer een aangepaste image te bouwen om de New Relic agent jar toe te voegen, wat frequentere updates van de agent mogelijk zou moeten maken.
Diagram

Wil je meer ontdekken over Kubernetes?

What others have also read


CloudBrew is altijd een hoogtepunt op onze kalender geweest, maar de editie van 2025 voelde anders. Misschien lag het aan de timing. Slechts een maand eerder, in november 2025, opende de Azure Belgium Central-regio eindelijk haar deuren. ACA opereert al altijd vanuit het hart van Europa, dus het live gaan van deze grote nationale mijlpaal net voor de conferentie zorgde voor een extra dosis enthousiasme.
Lees verder

Een betere uptime, lagere kosten en vendor lock-in vermijden. Dat zijn drie van de redenen waarom onze klanten kiezen voor een multicloud-strategie. Onze Cloud project manager Roel Van Steenberghe legt uit wat zo’n strategie precies inhoudt en wat de troeven zijn van Google Cloud Platform (GCP).
Lees verder

In de complexe wereld van moderne softwareontwikkeling worden bedrijven geconfronteerd met de uitdaging om verschillende applicaties die door verschillende teams worden ontwikkeld en beheerd, naadloos te integreren. De Service Mesh is van onschatbare waarde bij het overwinnen van deze uitdaging. In dit blogartikel verdiepen we ons in Istio Service Mesh en onderzoeken we waarom investeren in een Service Mesh zoals Istio een slimme zet is." Wat is Service Mesh? Een Service Mesh is een softwarelaag die verantwoordelijk is voor alle communicatie tussen applicaties, in deze context services genoemd. Het introduceert nieuwe functionaliteiten om de interactie tussen services te beheren, zoals monitoring, logging, tracing en verkeerscontrole. Een service mesh werkt onafhankelijk van de code van elke individuele service, waardoor het over netwerkgrenzen heen kan werken en kan samenwerken met verschillende beheersystemen. Dankzij een service mesh kunnen ontwikkelaars zich richten op het bouwen van toepassingsfuncties zonder zich zorgen te maken over de complexiteit van de onderliggende communicatie-infrastructuur. Istio Service Mesh in de praktijk Denk aan het beheren van een groot cluster waarop meerdere applicaties draaien die ontwikkeld en onderhouden worden door verschillende teams, elk met verschillende afhankelijkheden zoals ElasticSearch of Kafka. Na verloop van tijd resulteert dit in een complex ecosysteem van applicaties en containers, overzien door verschillende teams. De omgeving wordt zo ingewikkeld dat het voor beheerders steeds moeilijker wordt om het overzicht te bewaren. Dit leidt tot een reeks pertinente vragen: Hoe ziet de architectuur eruit? Welke applicaties interageren met elkaar? Hoe wordt het verkeer beheerd? Bovendien zijn er specifieke uitdagingen die voor elke afzonderlijke applicatie moeten worden aangepakt: Het afhandelen van aanmeldingsprocessen Implementeren van robuuste beveiligingsmaatregelen Netwerkverkeer beheren dat naar de applicatie wordt geleid ... Een Service Mesh, zoals Istio, biedt een oplossing voor deze uitdagingen. Istio fungeert als een proxy tussen de verschillende applicaties (services) in het cluster, waarbij elk verzoek door een component van Istio gaat. Hoe werkt Istio Service Mesh? Istio introduceert een sidecar proxy voor elke service in het microservices ecosysteem. Deze sidecar proxy beheert al het inkomende en uitgaande verkeer voor de dienst. Daarnaast voegt Istio componenten toe die het inkomende en uitgaande verkeer van het cluster afhandelen. Istio's control plane maakt het mogelijk om beleidsregels te definiëren voor verkeersbeheer, beveiliging en monitoring, die vervolgens worden toegepast op de toegevoegde componenten. Voor een beter begrip van de functionaliteit van Istio Service Mesh, zie ons blogartikel "Istio Service Mesh installeren: A Comprehensive Step-by-Step Guide" , een gedetailleerde, stapsgewijze uitleg over de installatie en het gebruik van Istio. Waarom Istio Service Mesh? Verkeersbeheer: Istio maakt gedetailleerd verkeersbeheer mogelijk, waardoor ontwikkelaars eenvoudig verkeer tussen verschillende versies van hun services kunnen routeren, verdelen en controleren. Beveiliging: Istio biedt een robuuste beveiligingslaag met functies zoals verkeersversleuteling met behulp van eigen certificaten, Role-Based Access Control (RBAC) en mogelijkheden voor het implementeren van authenticatie- en autorisatiebeleid. Waarneembaarheid: Door middel van ingebouwde instrumentatie biedt Istio diepgaande observeerbaarheid met tools voor monitoring, logging en gedistribueerde tracering. Hierdoor kunnen IT-teams de prestaties van services analyseren en snel problemen opsporen. Vereenvoudigde communicatie: Istio neemt de complexiteit van servicecommunicatie weg van applicatieontwikkelaars, zodat zij zich kunnen richten op het bouwen van applicatiefuncties. Is Istio geschikt voor uw opstelling? Hoewel de voordelen duidelijk zijn, is het essentieel om te overwegen of de extra complexiteit van Istio past bij jouw specifieke opstelling. Ten eerste is er een sidecar container nodig voor elke ingezette service, wat kan leiden tot ongewenste geheugen- en CPU overhead. Daarnaast kan het zijn dat je team niet beschikt over de specialistische kennis die nodig is voor Istio. Als je overweegt om Istio Service Mesh te gaan gebruiken, vraag dan begeleiding aan specialisten met expertise. Vraag onze experts gerust om hulp. Meer informatie over Istio Istio Service Mesh is een technologische game-changer voor IT-professionals die streven naar geavanceerde controle, beveiliging en observeerbaarheid in hun microservices-architectuur. Istio vereenvoudigt en beveiligt de communicatie tussen services, waardoor IT-teams zich kunnen richten op het bouwen van betrouwbare en schaalbare applicaties. Snel antwoord nodig op al uw vragen over Istio Service Mesh? Neem contact op met onze experts
Lees verderWant to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!

Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!

Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!

Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!

