Red Hat Leftovers
-
What is an edge-native application?
Cloud-native. Those two simple words redefined how we build, deploy, and even consume software. Twenty-five years ago, when I had hair I could pull on when having trouble with my code, the idea that I would use an office suite contained in my web browser would have sounded like science fiction. And yet, here we are. Gone are the days of installing an office suite from a pile of floppy disks. Naturally, the three or four years gap between releases is also a thing of the past. Nowadays, new features may appear anytime and anywhere, with no installation required. It's an understatement to say that the velocity of the software industry increased by an order of magnitude.
This evolution is a tremendous achievement from my perspective. Of course, if you are a bit younger than me or even one of those "cloud-native" developers who never experienced anything else, you surely see things differently. At this point, cloud-native is de facto how things are done—even for me. It is not exciting or new, just assumed. However, there are still applications living outside the cloud. Those applications are increasingly impacting our personal and professional lives. You see, software is eating the world. And this means cloud-native applications are increasingly supplemented with edge-native ones.
In this article, I will define edge applications and describe their characteristics. But before I get to that, it's important to understand how the cloud and edge environments differ.
-
How the GDB debugger and other tools use call frame information to determine the active function calls
In my previous article, I showed how debuginfo is used to map between the current instruction pointer (IP) and the function or line containing it. That information is valuable in showing what code the processor is currently executing. However, having more context for the calls that lead up to the current function and line being executed is also extremely helpful.
For example, suppose a function in a library has an illegal memory access due to a null pointer being passed as a parameter into the function. Just looking at the current function and line shows that the fault was triggered by attempted access through a null pointer. However, what you really want to know is the full context of the active function calls leading up to that null pointer access, so you can determine how that null pointer was initially passed into the library function. This context information is provided by a backtrace, and allows you to determine which functions could be responsible for the bogus parameter.
One thing’s certain: Determining the currently active function calls is a non-trivial operation.
-
Kubernetes Blog: Forensic container analysis
Authors: Adrian Reber (Red Hat)
In my previous article, Forensic container checkpointing in Kubernetes, I introduced checkpointing in Kubernetes and how it has to be setup and how it can be used. The name of the feature is Forensic container checkpointing, but I did not go into any details how to do the actual analysis of the checkpoint created by Kubernetes. In this article I want to provide details how the checkpoint can be analyzed.
Checkpointing is still an alpha feature in Kubernetes and this article wants to provide a preview how the feature might work in the future.
Preparation
Details about how to configure Kubernetes and the underlying CRI implementation to enable checkpointing support can be found in my Forensic container checkpointing in Kubernetes article.