v2.1
v2.0
v1.0
  1. Release Notes
    1. Release Notes - 2.1.1Latest
    1. Release Notes - 2.1.0
    1. Release Notes - 2.0.2
    1. Release Notes - 2.0.1
    1. Release Notes - 2.0.0
  1. Introduction
    1. Introduction
    1. Features
    1. Architecture
    1. Advantages
    1. Glossary
  1. Installation
    1. Introduction
      1. Intro
      2. Port Requirements
      3. Kubernetes Cluster Configuration
    1. Install on Linux
      1. All-in-One Installation
      2. Multi-Node Installation
      3. High Availability Configuration
      4. Air Gapped Installation
      5. StorageClass Configuration
      6. Enable All Components
    1. Install on Kubernetes
      1. Prerequisites
      2. Install on K8s
      3. Air Gapped Installation
      4. Install on GKE
    1. Pluggable Components
      1. Pluggable Components
      2. Enable Application Store
      3. Enable DevOps System
      4. Enable Logging System
      5. Enable Service Mesh
      6. Enable Alerting and Notification
      7. Enable Metrics-server for HPA
      8. Verify Components Installation
    1. Upgrade
      1. Overview
      2. All-in-One
      3. Multi-node
    1. Third-Party Tools
      1. Configure Harbor
      2. Access Built-in SonarQube and Jenkins
      3. Enable built-in Grafana Installation
      4. Load Balancer plugin in Bare Metal - Porter
    1. Authentication Integration
      1. Configure LDAP/AD
    1. Cluster Operations
      1. Add or Cordon Nodes
      2. High Risk Operations
      3. Uninstall KubeSphere
  1. Quick Start
    1. 1. Getting Started with Multi-tenancy
    1. 2. Expose your App Using Ingress
    1. 3. Compose and Deploy Wordpress to K8s
    1. 4. Deploy Grafana Using App Template
    1. 5. Job to Compute π to 2000 Places
    1. 6. Create Horizontal Pod Autoscaler
    1. 7. S2I: Publish your App without Dockerfile
    1. 8. B2I: Publish Artifacts to Kubernete
    1. 9. CI/CD based on Spring Boot Project
    1. 10. Jenkinsfile-free Pipeline with Graphical Editing Panel
    1. 11. Canary Release of Bookinfo App
    1. 12. Canary Release based on Ingress-Nginx
    1. 13. Application Store
  1. DevOps
    1. Pipeline
    1. Create SonarQube Token
    1. Credentials
    1. Set CI Node for Dependency Cache
    1. Set Email Server for KubeSphere Pipeline
  1. Logging
    1. Log Query
  1. Developer Guide
    1. Introduction to S2I
    1. Custom S2I Template
  1. API Documentation
    1. API Guide
    1. How to Access KubeSphere API
KubeSphere®️ 2020 All Rights Reserved.

Introduction to S2I

Source to image (S2I) is a command toolkit and workflow for building reproducible container images from source code. It places the source code into a Builder Image which is used to compile, then automatically encapsulate the source code and produce ready-to-run image by injecting source code into a container image.

You can refer to Source-to-Image for the use case. You can also reference the source code from S2IOperator and S2IRun for more information.

S2I Workflow

Builder Image

For dynamic languages like Python or Ruby, the build-time and run-time environments are the same. There are many built-in tools and dependencies needed for application runtime which are included in the builder image. For example, the Build Image of Ruby, it includes the packages like Bundler、Rake、Apache、GCC, etc. The following diagram illustrates the build workflow:

Builder Image

How Source-to-Image works

  1. Start a container from the builder image with the application source injected into a specified directory.
  2. Execute the assemble script of the builder image, it transforms that source code into the appropriate runnable program, such as installing dependencies with Bundler and moving the source code into a working directory.
  3. Set the image entrypoint to be a run script (provided by the builder image) that starts the container, and commit the new image, e.g. the final application image needed for the KubeSphere users.

How Source-to-Image works

Runtime Image

For compiled languages like Go, C, C++ or Java, the dependencies necessary for compilation may dramatically outweigh the size of the actual runtime artifacts. To keep runtime images slim, S2I enables a multiple-step build processes, where a binary artifact such as an executable or Java WAR file is created in the first builder image. Then S2I will extract and inject into a second image, i.e. runtime image, thus the application will run inside of this runtime image. The following diagram illustrates the build principle:

Runtime Image