Sometimes I write blog posts here and for other blogs, like this one:

https://developers.redhat.com/articles/2024/03/14/how-use-java-container-awareness-openshift-4

People will use that as reference and that’s great. You can even write your own blog post about it.

But better cite it because worse than copying someone’s work is to copy it wrongly.

Or the worst scenario: contrive (as make an unsubstantiated claim) just because of a misunderstanding of the concept, which you are probably not used to anyway.

Surfing online on the topic I can see some claims that are basically unsubstantiated and that’s just not how it works – sometimes AT ALL. The wording matters, some concepts are not interchangable and abstractions can do more harm than good.

So you are better citing the sources nonetheless. You may be reading something wrong yourself.

“Knowing enough about a subject to think you’re right. But not enough about the subject to know you’re wrong” — By Neil deGrasse Tyson.

A novela Kubanacan, desde pequeno traz elementos que muitos consideram problematica e com um final sem sentido (non-sense ending). Conteudo, em anos vendo e pensando a respeito, eu tenho DUAS interpretacoes possiveis para a novela como peça fictional de entretenimento:

a- trata-se de paradoxo temporal e, que o protagonista Esteban é o proprio pai dele.

b- a novela se trata de um sonho/imaginacao nos ultimos momentos de vida do Esteban.

Abaixo eu detalho essas explicaçoes in-universe – ou seja dentro da novela sobre isso. Não vou discutir elementos fora da novela, que sofreu varios problemas de produção e troca de roteiro.

PRIMEIRA INTERPRETACAO

Esteban eh o pai dele mesmo visto que se trata de um PARADOXO TEMPORAL EM LOOP INFINITO. Nessa interpretacao, a novela Kubanakan (2003) nao falhou no final mas trouxe o conceito de protagonista ser pai dele mesmo antes de DARK (2017) e parte do conceito de Predestination (2014) mas MUITO ANTES.

Em fato 15 anos antes quase (em relacao a DARK). A novela trouxe esse conceito (na epoca inovador) para as massas, seja querendo ou sem querer trouxe isso. Talvez a PRIMEIRA novela no mundo mundo a trazer esse conceito (alguns filmes e livros ja trazem isso em certa medida; Veja o filme: Os 12 macacos).

Sobre esse 1 ano de diferenca isso tem varias explicacoes dentro da novela (inside universe e fora dela (outside universe):

1. A mais simples eh: o registro foi feito ERRADO na hora – um erro desproposital.

2. Esteban foi resgistrado com um ano de diferença proposital para evitar algum problema/investigação.

Mas esse ELEMENTO EH A PARTE interessante do plot que SEMPRE LEVARA a duvida. Então a serie não tendo um fim deterministico. Sempre havera uma duvida: Sera que ele eh seu próprio pai?

SEGUNDA INTERPRETACAO

TODA a novela se trata dos ULTIMOS pensamentos (ou memorias) do protagonista Esteban enquanto ele MORRE NA PRAIA. Porque ele caiu. Por isso a novela começa e termina nessa cena.

Isso seria similar ao filme Once Upon a Time in America, onde o protagonista Noddles (Robert de Niro) . Essa interpretacao explica porque algumas coisas são desconexas non-sense e não batem: elas são da memoria/imaginacao dele. E faz todo sentido. O fato de nunca vermos ele morrer na tela ajuda nessa interpretacao. Sobre esse 1 ano de diferença no registro: isso seria parte do sonho/imaginação.

Mas esse ELEMENTO EH A PARTE interessante do plot que SEMPRE LEVARA a duvida. SERA que era tudo imaginação ou eram memórias? Sera que nada se tratava de realidade?

Termino aqui ressaltando que Kubanakan, apesar de todos os problemas – como terminou – trouxe um conceito diferente de final em aberto.

Being able to use OCP build configuration is a strong feature that improves the speed of deployment by a long margin.

Building images via docker/podman can be an very streamlined process, but build config directly on OCP provides a fast deployment procedure straight to be able to deploy pods/containers in such a way that the changes are applied very fast.

One does not need to use Tekton/Pipelines to be able to build a complete new image with complex settings, either with git source, dockerfile, or custom strategies. The deprecation of jenkins build configurations going towards Pipeline deployment – with Operator (with tasks that compose pipeline).

A simple build can be done in OCP in a few minutes and the image build straight to ImageStream, that can be used on the spot.

I mean, it is simple, powerful, easy to debug and can deploy containers (and therefore test images) on the spot right there and then. It is also very simple to debug – MAVEN settings can be easily added on the build. I like very much that the build has the logs so well linked so then the pods show the step done.

I think I already discussed this topic a few times here but it is interesting that requests and limits are N/A for java (JVM) perspective – OpenJDK will use limit as the mark for cpus.

And naturally, given the container’s cpu values are static (except on k8s 1.27) so then the limits will be inelastic.

Objectively, for the JVM basically limits will be used limits. The JVM won’t re-scale on the fly and will be ineslastic, and won’t re-scale on the fly so the number of threads (for instance parallel GC threads won’t change after the JVM has started). So the cpu details won’t fluctuate and this will change the GC threads or some deduced thread (pools that use cpu for calculation).

It is interesting that the JVM will actually round up the cpu for instance, so one pod with 5.2 cpu will end up being 6 cpus (with 2 cores and 2 threads per core for instance), depending on the K8S architecture below.

In any case collect the jcmd $PID VM.info to be able to display the values correctly and look for something like this:

→ CPU:total 4 (initial active 2) (2 cores per cpu, 2 threads per core): so 2 cpus == 4 cores == 8 threads.

Back on DG/EAP 7 we used to use template for Source to image deployments at some point.

In fact I liked template deployment of course you need to import the templates and such, but I don’t think it is bad from a functional perspective. And the Operator is so simple, it gives much more time for the user to focus on what matters.

I think helm charts will streamline this process, instead of templates. It is pretty interesting and very flexible in some ways.

## to install
helm install <release_name> chart <flags>  --> flags can be in the middle as well
## to upgrade
helm upgrade <release_name> chart <flags> --> flags can be in the middle as well
## to uninstall 
helm uninstall <release_name>

It is interesting to handle the pod’s yaml directly on the statefulset/route instead of the custom resources, which is the default by the operator. It is a sense of a flexibility and responsibility as well, given there is much more room for the user to screw up.

I love Avatar, both of them, great movie. Made by a Canadian. Astonishing images. Back in year ago when I was released, but still have impressive images. Pandora is amazing.

However, the second has one main problem: it is 100% plot driven – not character driven. That’s not a spoiler, but be aware that the characters won’t make hard choices and set up a path for adventures. It is pretty much the opposite, the plot happens despite the characters’ choice.

Basically there is only one character that drive the plot: the whale and maybe the “bad guys” as well and one/two difficult choices. No big dilemma or little components that make the character choices critical ending.

The movie is not bad though, but probably on the Avatar series it won’t be the top 1st best.

At some point I gave up the plot and only was seeing the movie, like I used to watch Windows media player would create just for the music.

I mean arguably, one can image several scenarios and how each character should behave. And the end result may not even be better than the final result. But changing some part of the script, not 100% the fundamental here, the result would be 2x better and the characters would be much more relatable. Because we relate with characters that make choices, even bad ones.

But the explanation is likely because there will be several movies, so this one is just setting up some stones so then the next movies there will be some dilemmas and hard choices.

Working with Openshift in a daily basis, I come with several situations where the pod crashes. Given my background on java, I will talk about java here.

Let me list a few situations and the next steps

pods crash with OOME	The java process uses more heap than it was suppose – it would generate a heap on OOME exception – but it might exit given: ExitOnOutOfMemoryError
pods crash with OOME killer	Verify OCP node dmesg and verify if there is OOME Killer messages

How to know why my pod is crashing?

Let’s pretend you don’t know why the java pod (java pod here == pod with one container that is java). The first would be to see if the pod is OOME (in the JVM) or suffering from OOME-killer.

OOME will be handled by the JVM itself however, because the containers usually have ExitOnOOME so then the container will exit, which will prompt the orchestrator to respawn new pods given a certain timeout period.

For OOME Killers, this is an external agent (OCP node, or the cgroups) acting out and affecting the container to finish it up given a certain condition. Like lack of resources if the OCP (kubelet) needs to spawn a certain pod but doesn’t have resources, so it might just terminate the QoS best efforts ones over spawning Guaranteed pods.

Or that can be a native allocation breaching the cgroups limitations and causing the container to exit, by being killed.

Complementary to getting the jcmd VM.native_memory, the jcmd command VM.info, which I discussed a few times on this blog can be an awesome tool for investigating (native) leaks. This feature requires 8u222 or later if I’m not mistaken.

In fact, for containers, I would just get jcmd VM.info directly, which in fact has the jcmd VM.native_memory. So VM.info can, easily be used instead – Native memory info will be on the VM.info.

jcmd PID VM.info

VM.info will show detailed summary of the VM and the OS, including the native details and shared libraries – the native details will only show if Native Memory Tracking flags: -XX:NativeMemoryTracking=summary or XX:NativeMemoryTracking=details are there. Otherwise VM.info won’t display this section – but other sections will be there regardless.

I was reading the book Hybrid Cloud Apps with OCP again – that’s an awesome book by Michael Elder at al, and the only comment I would add is about networking/ DNS. The book could add more about networking and how it changed from OCP 3.x to OCP 4.x.

In some scenarios of lack resource of the kuberntes/ocp nodes, the pod Quality of Service, can play a role on the nodes eviction process and how they can terminate the pods, the types of quality set on the pods, either guaranteed, burstable, and best effort.

We do that on the deployment/deployment config – for usual deployments (no operator) involved.

In an Operator deployment for example, the Infinispan operator, setting the container specs in the Infinispan CR with cpu and memory with the same values will make it guaranteed.

And this setting can have a huge impact on the stability of critical nodes in case the OCP nodes decided to start killing ocp pods. The BestEffort will be the first on the list, followed by Burtable and Guaranteed pods will be the last one on the kill list.

Although a small setting this can have huge consequences for OOME Kill (or avoiding it).

Recently I’ve been working in some interesting OCP deployments with Service Mesh. I mean that is a very powerful and I’d say complicates subject – even for experts on the matter doesn’t seem trivial.

The context here is Istio, just to be clear. So I’m talking about the Cloud Native Computing Foundation project. Service Mesh is basically an extension of OCP where it provides customizable features. In this matter, Service mesh can add so much flexility and enables such a centralized control for microservices handling.

Features of Service mesh include load balancing, full/automatic authentication canary releases, access control and even end-to-end authentication (via Istio mtls). Everything in one place.

Objectively Service Mesh adds a transparent layer of transport – all without any application change. To do that Service Mesh
captures/intercepting traffic between services that will act to modify, redirect, or create new requests to other services.

To do this interception/capture of requests, Service Mesh relies on the envoy sidecar – which is a container together with the other application in the same pod – a sidecar.

For deployments such as JBoss EAP/Widlfly this can be very interesting for be able to control communication and establish a level of network control more than what the services (eap-app-ping for clustering) already provide.

On the other hand, some architectures are coming up to use Istio without the sidecar, called sidecarless. One example is Ambient Mesh. So sidecarless implementations can be useful for environments where instrumenting the pod increases its complexity (deployment and instrumentation) and where it can be just simpler to not instrument the pod.