YAML 1.2 only is supported

[feloy]

Describe the bug

Library uses a YAML parser compatible with YAML 1.2 only, when Kubernetes is mostly compatible with YAML 1.1 (https://kubernetes.io/docs/concepts/configuration/overview/#:~:text=YAML%201.2%20only%20recognizes%20true,cause%20unexpected%20errors%20or%20behaviors.)

Client Version

main

Server Version

1.31

To Reproduce

See example code below

Expected behavior

The value 0644 in the manifest is correctly recognized a an octal value with Kubernetes tools, but not with the function loadYaml from this library

Example Code

import * as k8s from '@kubernetes/client-node';
import { EventType, State } from 'js-yaml';

const manifest = `
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: contour
  name: contour
  namespace: projectcontour
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      # This value of maxSurge means that during a rolling update
      # the new ReplicaSet will be created first.
      maxSurge: 50%
  selector:
    matchLabels:
      app: contour
  template:
    metadata:
      labels:
        app: contour
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchLabels:
                  app: contour
              topologyKey: kubernetes.io/hostname
            weight: 100
      containers:
      - args:
        - serve
        - --incluster
        - --xds-address=0.0.0.0
        - --xds-port=8001
        - --contour-cafile=/certs/ca.crt
        - --contour-cert-file=/certs/tls.crt
        - --contour-key-file=/certs/tls.key
        - --config-path=/config/contour.yaml
        command: ["contour"]
        image: ghcr.io/projectcontour/contour:v1.30.2
        imagePullPolicy: IfNotPresent
        name: contour
        ports:
        - containerPort: 8001
          name: xds
          protocol: TCP
        - containerPort: 8000
          name: metrics
          protocol: TCP
        - containerPort: 6060
          name: debug
          protocol: TCP
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8000
        readinessProbe:
          tcpSocket:
            port: 8001
          periodSeconds: 10
        volumeMounts:
          - name: contourcert
            mountPath: /certs
            readOnly: true
          - name: contour-config
            mountPath: /config
            readOnly: true
        env:
        - name: CONTOUR_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: POD_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.name
      dnsPolicy: ClusterFirst
      serviceAccountName: contour
      securityContext:
        runAsNonRoot: true
        runAsUser: 65534
        runAsGroup: 65534
      volumes:
        - name: contourcert
          secret:
            secretName: contourcert
        - name: contour-config
          configMap:
            name: contour
            defaultMode: 0644
            items:
            - key: contour.yaml
              path: contour.yaml
`;

class MyKubernetesObjectApi extends k8s.KubernetesObjectApi {
  public async getSerializationType(apiVersion?: string, kind?: string): Promise<string> {
    return super.getSerializationType(apiVersion, kind);
  }
}

const kc = new k8s.KubeConfig();
kc.loadFromDefault();

const client = MyKubernetesObjectApi.makeApiClient(kc) as MyKubernetesObjectApi;

const yml = k8s.loadYaml<k8s.KubernetesObject>(manifest);

client.create(yml).then(() => {
  console.log('==> created');
}).catch((err: unknown) => {
  console.error(err);
});

Environment (please complete the following information):

• OS: Mac
• Node.js version 22.16

Additional context

Related issue on js-yaml library: nodeca/js-yaml#684

[brendandburns]

Thanks for reporting this. It seems like a low-priority to fix this, given that you could always do the parsing outside of this library, but if you want to submit a PR, we'll review it.

[feloy]

@brendandburns Would changing the parser from js-yaml to yaml be a possibility (I don't know the history of the project, perhaps this library has been chosen for specific reasons?). The yaml supports both YAML 1.1 and 1.2, which would help to resolve the problem

[mstruebing]

js-yaml seems pretty unmaintained, last commit was 3 years ago and the last release 4 years ago, even though it's widely used.
yaml on the other hand is maintained by one person from mozilla but seems to be actively maintained.

So I would think sooner or later we need to switch to a different library anyway if js-yaml maintenance isn't getting traction again, and it doesn't seem like that will be the case.

yaml seems like a good alternative to me.

WDYT @brendandburns ?

[brendandburns]

That switch is fine to me as long as we can maintain compatibility for users of this library.

[Tanmay-008]

The yaml library supports both yaml 1.1 and 1.2, but,By default, yaml follows the rules of yaml 1.2. @brendandburns @feloy @mstruebing

[k8s-triage-robot]

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

This bot triages un-triaged 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:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue 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.

This bot triages un-triaged 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:

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

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

/lifecycle rotten