Am I reading this correctly as Kuberetes-powered fighter jets? That's certainly not going to shoot anyone in the foot...
"Good news, General. We've found a way to lower maintenance costs in the cockpit systems by 10% if we removed this thing here on the blueprints, so we've already gone ahead with that change."
"But that's the emergency ejection system!"
"Yes, and our data indicates that it's almost never used. It doesn't really make sense to devote manpower to keeping a system running that few people ever need. If we get rid of it, we can free up developer-hours to making the canopy opening/closing action a little smoother. Everyone uses the canopy."
That said, how can you not wince reading, "To do this, Lockheed wanted to adopt principles and frameworks common in software lexicon like agile, scrum, minimum viable product (MVP) and DevSecOps."
They later talk about agile vs waterfall as well as devops. It doesn't read like this is going on a plane, probably just dev and test environments.
Instead of having separate computers, you now tend to have fewer "servers" which run multiple modules in isolated partitions, communicating over the common network using unidirectional messages; whether using SAE AS5643 - aka IEEE-1394 - like in F-35 and X-47, or over mutated Ethernet known as AFDX (A380, A350, B787).
However a big portion of JSF issues is also in ground software - there's a dedicated set of platforms required to operate F-35, which is also known for infamously depending on connectivity to Lockheed servers or the airplane stops working.
The system involved, ALIS, had als infamously took more time to deploy during a test squadron redeployment than the whole redeployment - which I guess they might be trying to speed up using Kubernetes.
From what I heard ALIS appears to still be done the same style as certain other logistics software from lockheed back in 2010, and that doesn't say anything good.