Issue with PatchDeployment Using Kubernetes Client in C# After Upgrade

[CleverFool77]

Issue with PatchDeployment Using Kubernetes Client in C# After Upgrade

I recently upgraded Kubernetes from version 3.x.x to 15.x.x (By the time this team looked up, KubernetesClient had already sprinted to 15.x.x), and I am encountering issues with patching an existing Deployment using the Kubernetes client in C#. Here's the scenario:

---

Previous Code (Working in Kubernetes 3.x.x)

The following method was used to patch a Deployment successfully in version 3.x.x:
The client below is the wrapper class for the Kubernetes client.

private async Task PatchDeployment(V1Deployment serviceSpec, string deploymentName, string ns, CancellationToken cancellationToken)
{
    var jsonPatch = new JsonPatchDocument<V1Deployment>();
    jsonPatch.Replace(e => e.Spec, serviceSpec.Spec);
    jsonPatch.Operations.ForEach(x => x.path = x.path.ToLower());

    V1Patch updateSpec = new V1Patch(jsonPatch, V1Patch.PatchType.JsonPatch);
    await client.PatchNamespacedDeploymentAsync(updateSpec, deploymentName, ns, cancellationToken: cancellationToken);
    logger.LogInfoLine($"Deployment '{serviceSpec.Metadata.Name}' successfully updated with spec {serviceSpec.AsJsonString()}.");
}

---

The Problem After Upgrade

After upgrading Kubernetes to version 15.x.x, the same code fails with the following error: As if it's receiving empty values in jsonpatch instead of existing deployment with updated patch values.

{
    "kind": "Status",
    "apiVersion": "v1",
    "metadata": {},
    "status": "Failure",
    "message": "Deployment.apps \"abc\" is invalid: [spec.template.spec.containers[0].name: Required value, spec.template.spec.containers[0].image: Required value]",
    "reason": "Invalid",
    "details": {
        "name": "abc",
        "group": "apps",
        "kind": "Deployment",
        "causes": [
            {
                "reason": "FieldValueRequired",
                "message": "Required value",
                "field": "spec.template.spec.containers[0].name"
            },
            {
                "reason": "FieldValueRequired",
                "message": "Required value",
                "field": "spec.template.spec.containers[0].image"
            }
        ]
    },
    "code": 422
}

---

What I've Tried

1. Logging the jsonPatch Document:

   • I confirmed that the jsonPatch contains valid values before sending it.

2. Alternative Patch Serialization:

   • In a similar case while patching a ConfigMap, I encountered a similar issue. I resolved it by explicitly serializing the patch object into JSON before creating the V1Patch object:

     V1Patch updateData = new V1Patch(JsonConvert.SerializeObject(jsonPatch), V1Patch.PatchType.JsonPatch);

   • However, applying this to the Deployment patch did not resolve the issue.

3. Validating the Input V1Deployment:

   • I ensured that the serviceSpec object contains valid Spec, Template, and Containers fields. All required fields are present, and the serviceSpec.Spec.Template.Spec.Containers array contains a valid container definition.

4. Ensuring Patch Type Consistency:

   • I confirmed using the correct JsonPatchDocument and V1Patch.PatchType.JsonPatch.

---

Questions

1. Why am I still getting the 422 Unprocessable Entity error even though the jsonPatch document contains all the correct fields and values?
2. Is there a change in how the Kubernetes API server validates PATCH requests between version 3.x.x and 15.x.x that could be causing this?
3. Is explicit JSON serialization of the JsonPatchDocument required for patching a Deployment in newer Kubernetes versions? If so, why does the direct use of JsonPatchDocument fail in this case?

I would really appreciate if someone can help me solve my doubts.

[tg123]

see #772

[CleverFool77]

Thanks for the reply. I’ve been trying to patch a Kubernetes deployment using a JSON patch approach provided in mentioned discussion section, but I keep running into this error: Let me know which one of the below approach I should go for.

What I’ve Tried

1. Using Newtonsoft.Json.JsonPatchDocument:

    jsonPatch.ContractResolver = new DefaultContractResolver
           {
               NamingStrategy = new CamelCaseNamingStrategy()
           };
           jsonPatch.Replace(e => e.Spec, serviceSpec.Spec);
           jsonPatch.Operations.ForEach(x => x.path = x.path.ToLower());
           V1Patch updateSpec = new V1Patch(Newtonsoft.Json.JsonConvert.SerializeObject(jsonPatch), V1Patch.PatchType.JsonPatch);
           await client.PatchNamespacedDeploymentAsync(updateSpec, deploymentName, ns, cancellationToken: cancellationToken);
           logger.LogInfoLine($"Deployment '{serviceSpec.Metadata.Name}' successfully updated with spec {serviceSpec.AsJsonString()}.");
       }

   • Result: Still got same error as before
     Unprocessable Entity response: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Deployment.apps \\

2. Switching to System.Text.Json :

   var serializeOptions = new JsonSerializerOptions
   {
       PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
       WriteIndented = true
   };
   
   var old = System.Text.Json.JsonSerializer.SerializeToDocument(new existingDeployment, serializeOptions);
   
   var expected = System.Text.Json.JsonSerializer.SerializeToDocument(serviceSpec, serializeOptions);
   
   var patch = old.CreatePatch(expected);
   
   Console.WriteLine("JSON Service Spec Patch: " + patch.AsJsonString());
   
   V1Patch updateSpec = new V1Patch(patch, V1Patch.PatchType.JsonPatch);
   await client.PatchNamespacedDeploymentAsync(updateSpec, deploymentName, ns, cancellationToken: cancellationToken);
   logger.LogInfoLine($"Deployment '{serviceSpec.Metadata.Name}' successfully updated with spec {serviceSpec.AsJsonString()}.");

   • Result: below Error

Failed to patch Kubernetes Deployment for module 'abc': 
Self referencing loop detected for property 'root' with type 'System.Text.Json.Nodes.JsonValueOfElement'. 
Path 'operations[0].value'.

---

• Are you expecting second approach to be followed ?

[CleverFool77]

Issue Resolved: Using Manual PatchOperations Instead of JsonPatchDocument

Hi all,
I wanted to share an update that I’ve successfully resolved the issue by bypassing the JsonPatchDocument approach. Instead, I implemented manual patch operations using a List<object> and serialized it into a JSON Patch. This method avoids the additional complexities and dependencies on the JsonPatch package.

Solution: Manual PatchOperations

var patchOperations = new List<object>
       {
           new
           {
               op = "replace",
               path = "/spec",
               value = serviceSpec.Spec
           }
       };

var jsonPatch = System.Text.Json.JsonSerializer.Serialize(patchOperations); // Serialize the patch
var updateData = new V1Patch(jsonPatch, V1Patch.PatchType.JsonPatch); // Wrap into V1Patch

logger.LogInfoLine($"Patch content: {jsonPatch}"); // Log for debugging