Error creating deployment with deployment.yaml file - Unknown apiVersionKind apps/v1/Deployment is it registered?

[cdkgenie]

I am creating a deployment using deployment.yaml file below with version 15.0.1 (Current Latest)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp-sample
spec:
  selector:
    matchLabels:
      app: demoapp-sample
  replicas: 1
  template:
    metadata:
      labels:
        app: demoapp-sample
    spec:
      containers:
        - name: demoapp
          image: test/demoapp
          # Image that will be used to containers in the cluster
          imagePullPolicy: Always
          ports:
            - containerPort: 9005
              # The port that the container is running on in the cluster

My java code is, in which resourceFile object has the deployment.yaml content:

try {
            ApiClient client = ClientBuilder.cluster().build();
            Configuration.setDefaultApiClient(client);
            AppsV1Api api = new AppsV1Api();
            V1Deployment yamlDeployment = (V1Deployment) Yaml.load(new InputStreamReader(resourceFile.getInputStream()));
            V1Deployment createResult = api.createNamespacedDeployment("default", yamlDeployment, null, null, null, null);
            System.out.println(createResult);
            return "Deployment created successfully.";
        } catch (Exception e) {
            e.printStackTrace();
            return e.getMessage();
        }

My cluster-role.yaml file for the container running the above code is:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: demo-cluster-role
rules:
  - apiGroups: ["","apps"]
    resources: ["pods","deployments","services"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

So I have permissions to create the deployments. But when I run this code, Im getting exception as

Unknown apiVersionKind apps/v1/Deployment is it registered?

How can I resolve this issue?

[cdkgenie]

Added the following line to resolve the issue. Note: That method is deprecated.

Yaml.addModelMap("apps/v1","Deployment", V1Deployment.class);

[brendandburns]

Glad that helps, but that should be loaded for you automatically based on this static initializer:

java/util/src/main/java/io/kubernetes/client/util/ModelMapper.java

Line 76 in 621e23d

initModelMap();

Is there something weird/different about your classloaders?

[cdkgenie]

I use spring boot, don't know what is causing that issue. but without that, it was not working.

[yue9944882]

i suppose it's related to #1659

[yue9944882]

@cdkgenie can you try init the model mapping via calling the following method to perform a full on-line api-discovery?

java/util/src/main/java/io/kubernetes/client/util/ModelMapper.java

Line 239 in f107f7a

public static Set<Discovery.APIResource> refresh(Discovery discovery) throws ApiException {

[pgalache]

If you are executing from a fatJar, the initModelMap won't find the api classes from the model.

You can add them manually by ModelMapper.addModel for every K8s object you use. Or alternatively, while #1659 is not fixed, you could create the Docker container exploding the fatJar (which is what buildpacks do, for example) so you won't be executing a fatJar and it should work.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[theAkito]

You can add them manually by ModelMapper.addModel

1. Why is it deprecated, if there is no replacement or fix for it? Or is there one?
2. Can anyone give an actual code example, instead of just abstractly mentioning it?

How would the string arguments actually look like for the following kinds?

• V1Namespace
• V1ServiceAccount
• V1ClusterRoleBinding
• V1ConfigMap
• V1Deployment

[kitovraz]

@PostConstruct
public void init() {
ModelMapper.addModelMap("", "v1", "Pod", "Pods", V1Pod.class, V1PodList.class);
}

[wkclz]

When I running my app in IDEA, it is OK, but when running as a jar (java -jar xxx.jar), this problem is appear:
with remote debug, the callstack is:

1. Yaml.load("Yaml string")
2. ModelMapper.getApiTypeClass(apiVersion, kind);
3. static {initModelMap();}
4. getClassNamesFromPackage
5. processJarPackage
6. I see the packageURL is like: nested:/home/apps.jar/!BOOT-INF/lib/client-java-api-19.0.0.jar!/io/kubernetes/client/openapi/models
7. jarFileName = jarFileName.substring(5, jarFileName.indexOf("!"));： d:/home/apps.jar/, so it can scan any package to deserialize the yaml, and we got "XXXXX is it registered?"

[wkclz]

I fixd this bug:
io.kubernetes.client.util.ModelMapper

  private static void processJarPackage(URL packageURL, String packageName, String pkg, ArrayList<String> names) throws IOException {
      logger.info("Loading classes from jar {}", packageURL.getFile());
      try (JarFile jf = ((JarURLConnection) packageURL.openConnection()).getJarFile()) {
          Enumeration<JarEntry> jarEntries = jf.entries();
          while (jarEntries.hasMoreElements()) {
              processJarEntry(jarEntries.nextElement(), packageName, pkg, names);
          }
      }
  }