Levis is Kubernetes Manifest Generator for simply creating Kubernetes applications. Levis generates pure Kubernetes YAML - you can use Levis to define Kubernetes applications with YAML syntax for any Kubernetes clusters running anywhere.

This is an project built with ❤️ by KubeOps Skills. We encourage you to try it out, leave feedback, and jump in to help!

• Versioning
• Demo
• Getting Started
• Help & Feedback
• Examples
• Roadmap
• Contributing
• License

Levis is available on Linux, macOS and Windows platforms.

• Binaries for Linux, Windows and Mac are available as tarballs in the release page.

Interacting with the community and the development team is a great way to contribute to the project. Please consider the following venues (in order):

• Search open issues
• Slack: #project channel in levis

See our Examples Directory.

See our roadmap for details about our plans for the project

We welcome community contributions and pull requests. See our contribution guide for more information on how to report issues, set up a development environment and submit code.

This project is distributed under the MIT License, Copyright (c) 2021 KUBEOPS SKILLS Co., Ltd.

Use levis create -f <levis-config-file>.yaml schema to generate Kubernetes Component Syntax

This is an example levis config

levis:
  name: "nginx"
  namespace: "kubeops"
  deployment:
    name: "nginx"
    labels:
      app: nginx
      run: nginx
    annotations:
      app: nginx
      nginx.master: "true"
    serviceAccount: microservice
    revisionHistoryLimit: 5
    replicas: 3
    strategy: 
      type: RollingUpdate
      rollingUpdate:
        maxSurge: "80%"
        maxUnavailable: "20%"
    matchLabels:
      app: nginx
      run: nginx
    containers:
      name: "nginx"
      image: "nginx"
      imagePullPolicy: Always
      port: 8080
      env:
        app: nginx
      envField:
        - KEY: "value"
          AGENT_HOST: "status.hostIP"
        - apiVersion: v2
          HOST_NAME: 
      configEnvName: "appsettings"
      secretEnvName: "secretappsettings"
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"
      livenessProbe:
        path: /actuator/health/liveness
        port: "8080"
        initialDelaySeconds: 30
        periodSeconds: 10
        successThreshold: 10
        failureThreshold: 10
        timeoutSeconds: 10
      readinessProbe:
        path: /actuator/health/readiness
        port: "8080"
        initialDelaySeconds: 30
        periodSeconds: 10
        successThreshold: 10
        failureThreshold: 10
        timeoutSeconds: 10
  service:
    name: "nginx"
    labels:
      app: nginx
    annotations:
      app: nginx
    selector:
      app: nginx
    type: ClusterIP
    ports:
      name: "nginx"
      port: 80
      targetPort: 80

For more information, you can follow levis syntax example from this link

A Deployment provides declarative updates for Pods and ReplicaSets.

The following are typical use cases for Deployments:

• Create a Deployment to rollout a ReplicaSet. The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
• Declare the new state of the Pods by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
• Rollback to an earlier Deployment revision if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
• Scale up the Deployment to facilitate more load.
• Pause the Deployment to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
• Use the status of the Deployment as an indicator that a rollout has stuck.
• Clean up older ReplicaSets that you don't need anymore.

reference: link

The following is an example of a Deployment. It creates a kubernetes configuration to bring up nginx Pods and Service:

levis:
  name: "nginx"
  deployment:
    containers:
      image: "nginx"
  service:
    enable: true

this example: [link] (https://github.com/kubeopsskills/levis/blob/develop/examples/levis.yaml)

This is metadata about the resource, such as its name, type, api version, annotations, and labels. This contains fields that maybe updated both by the end user and the system (e.g. annotations, labels and so on).

deployment:
  name: "nginx"
  labels:
    app: nginx
    run: nginx
  annotations:
    app: nginx
    nginx.master: "true"

The following tables list the configurable parameters of the metadata chart and their default values.

You can visualize and manage Kubernetes objects with more tools than kubectl and the dashboard. A common set of labels allows tools to work interoperably, describing objects in a common manner that all tools can understand.

deployment:
  labels:
    app.kubernetes.io/name: "nginx"
    app.kubernetes.io/instance: "nginx-01"
    app.kubernetes.io/version: "1.1.0-stable"
    app.kubernetes.io/component: "reverse-proxy"
    app.kubernetes.io/part-of: "api-gateway"
    app.kubernetes.io/managed-by: "levis"
    app.kubernetes.io/created-by: "controller-manager"

You can use Kubernetes annotations to attach arbitrary non-identifying metadata to objects. Clients such as tools and libraries can retrieve this metadata.

deployment:
  annotations:
    registry: "https://hub.docker.com/"
    credential: "secret-manager"

references:

• Recommended Labels
• Annotations

When you specify a Pod, you can optionally specify how much of each resource a Container needs. The most common resources to specify are cpu and memory (RAM); there are others.

When you specify the resource request for Containers in a Pod,

• the scheduler uses this information to decide which node to place the Pod on.

When you specify a resource limit for a Container,

• the kubelet enforces those limits so that the running container is not allowed to use more of that resource than the limit you set.

The kubelet also reserves at least the request amount of that system resource specifically for that container to use.

If the node where a Pod is running has enough of a resource available, it's possible (and allowed) for a container to use more resource than its request for that resource specifies. However, a container is not allowed to use more than its resource limit.

• For example, if you set a memory request of 256 MiB for a container, and that container is in a Pod scheduled to a Node with 8GiB of memory and no other Pods, then the container can try to use more RAM.

If you set a memory limit of 4GiB for that Container, the kubelet (and container runtime) enforce the limit. The runtime prevents the container from using more than the configured resource limit.

• For example: when a process in the container tries to consume more than the allowed amount of memory, the system kernel terminates the process that attempted the allocation, with an out of memory (OOM) error.

Limits can be implemented either reactively (the system intervenes once it sees a violation) or by enforcement (the system prevents the container from ever exceeding the limit). Different runtimes can have different ways to implement the same restrictions.

deployment:
  ...
  containers:
  ...
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  ...

The following tables list the configurable parameters of the resource chart and their default values.

References:

• Managing Resources for Containers
• Requests and Limits

• CHANGELOG-1.0.3.md
• CHANGELOG-1.0.2.md
• CHANGELOG-1.0.1.md
• CHANGELOG-1.0.0.md

Our Commitment to Open Source can be found here

1. Fork this repository to your own GitHub account and then clone it to your local device.
2. Create a new branch git checkout -b MY_BRANCH_NAME
3. Update new source code to your branch with GPG sign
4. Pull request from your branch into this repository main branch
5. Waiting for reviewing from owners
6. Accept to pull request / Reject with comment to adjust your pull request