add k8s interop content

Signed-off-by: Will Tsai <[email protected]>

docs/content/guides/author-apps/containers/overview/index.md

@@ -8,41 +8,63 @@ categories: "Overview"
 tags: ["containers"]
 ---
 
-A Radius container provides an abstraction to model and run your container workloads as part of your Radius application. 
+A Radius container enables you to run a container workload as part of your application across different platforms and runtimes. Your container can be a frontend UI, a backend API, a database, or any other container you need to run as part of your app. Plus, with Radius connections, you can easily connect your container to other resources in your application, such as databases, message queues, and more and automatically configure your container with identity, secrets, and other configuration.
 
-{{< rad file="snippets/container.bicep" embed=true marker="//CONTAINER" >}}
+<img src="containers-splash.png" alt="Container graphic" width=300px >
+
+> Adding a container and want to jump to the reference docs? Check out the [container resource schema]({{< ref "container-schema" >}}).
 
 ## Supported runtimes
 
-Containers are run on the same Kubernetes cluster as your [Radius installation]({{< ref "guides/operations/kubernetes" >}}). We plan to support additional container runtimes and configurations in the future
+Radius containers are portable across container runtimes, allowing you to define your container workload once and run it on any of the supported runtimes.
+
+### Kubernetes
+
+Containers are deployed to the same Kubernetes cluster as your Radius installation, into the namespace that is defined in your application. For more information on how Radius resources map to Kubernetes objects, refer to the [Kubernetes mapping guide]({{< ref "/guides/operations/kubernetes/overview#resource-mapping" >}}).
+
+#### Customize Kubernetes configurations
+
+Radius provides a way to apply custom Kubernetes configurations to container resources that are created by Radius. This allows you to make use of Kubernetes configurations or features that are not supported by Radius, yet remain composable with other Radius features like [Connections]({{< ref "guides/author-apps/containers/overview#connections" >}}). Additionally, it provides a way to migrate your existing Kubernetes applications into Radius without having to rewrite your Kubernetes configurations, while giving you the option to incrementally adopt Radius features over time. The customizations are applied to the container resource via the [`runtimes`]({{< ref "reference/resource-schema/core-schema/container-schema/_index.md#runtimes" >}}) property within the container resource definition.
+
+##### Base Kubernetes YAML
 
-## Capabilities
+You can provide a Kubernetes YAML definition as a base or foundation upon which Radius will build your containers, enabling you to incrementally adopting Radius by starting with your existing YAML definition and use applying Radius customizations on top. The provided YAML is fully passed through to Kubernetes when Radius creates the container resource, which means that you may even provide a definition for a CRD that Radius has no visibility into. <!-- For more information on how to onboard existing Kubernetes resources into Radius, refer to the [base Kubernetes YAML guide]("guides/author-apps/kubernetes/how-to-yaml-base-support"). -->
 
-Radius containers enables you to specify the image for the container, the ports the container provides and consumes, the environment variables to set, the volumes to mount, and the probes to run.
+Radius currently supports the following Kubernetes resource types for the `base` property: 
 
-Additionally you can customize the behavior of the containers with the help of [extensions](#extensions).
+| Kubernetes Resource Types | Number of resources | Limitation |
+|---------------------------|---------------------|------------|
+| Deployment | 1 | Deployment name must match the name of the Radius container |
+| ServiceAccount | 1 | ServiceAccount name must match the name of the Radius container using the correct namespace |
+| Service | 1 | ServiceAccount name must match the name of the Radius container using the correct namespace |
+| Secrets | Multiple | No limitation except within the respective namespace |
+| ConfigMap | Multiple config maps | No limitation except within the respective namespace |
 
-### Image
+##### Pod patching
 
-An image can be specified for your container workload to pull and run. Refer to the [container reference docs]({{< ref container-schema >}}) for more information on image requirements.
+You can also "patch" the Kubernetes containers created and deployed by Radius using [PodSpec](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) definitions. This allows for setting Kubernetes-specific configurations, as well as overriding Radius behaviors, which means that you may access all Kubernetes Pod features, even if they are not supported by Radius. <!-- For more information on how to patch Kubernetes pods, refer to the [Kubernetes pod patching guide]("guides/author-apps/kubernetes/how-to-patch-pod"). -->
 
-If you want to pull the container image from a private container register, you need to allow access from your Kubernetes cluster. Follow the documentation to [configure private container registries access]({{< ref "guides/operations/kubernetes/supported-clusters#configure-container-registry-access" >}}).
+## Container definition
+
+Radius containers allow you to specify your image, ports, environment variables, volumes, and more. Refer to the [container resource schema]({{< ref "container-schema" >}}) for more information.
 
 ### Ports
 
 Ports allow you to expose your container to incoming network traffic. Refer to the [networking guide]({{< ref networking >}}) for more information on container networking.
 
-### Volumes
+## Volumes
 
-The volumes mounted to the container, either ephemeral or persistent, are defined in the volumes section.
+Volumes can be mounted to the container to provide access to data. There are two types of volumes, ephemeral and persistent.
 
 Ephemeral volumes have the same lifecycle as the container, being deployed and deleted with the container. They create an empty directory on the host and mount it to the container.
 
 Persistent volumes have life cycles that are separate from the container. Containers can mount these persistent volumes and restart without losing data. Persistent volumes can also be useful for storing data that needs to be accessed by multiple containers.
 
-### Probes
+## Health Probes
+
+Health probes are used to determine the health of a container. There are two types of probes, readiness and liveness. For more information on how to setup health probes, refer to the [container resource schema]({{< ref "container-schema" >}}).
 
-#### Readiness Probe
+### Readiness Probe
 
 Readiness probes detect when a container begins reporting it is ready to receive traffic, such as after loading a large configuration file that may take a couple seconds to process. There are three types of probes available, httpGet, tcp and exec. 
 
@@ -54,7 +76,7 @@ For an **exec probe**, a command is run within the container. A return code of 0
 
 Refer to the readiness probes section of the [container resource schema]({{< ref "container-schema#readiness-probes" >}}) for more details.
 
-#### Liveness Probe
+### Liveness Probe
 
 Liveness probes detect when a container is in a broken state, restarting the container to return it to a healthy state. There are three types of probes available, httpGet, tcp and exec.
 
@@ -66,45 +88,39 @@ For an **exec probe**, a command is run within the container. A return code of 0
 
 Refer to the probes section of the [container resource schema]({{< ref "container-schema#liveness-probes" >}}) for more details.
 
-### Connections
+## Connections
 
 When a connection between two resources is declared, Radius injects resource related information into environment variables that are then used to access the respective resource without having to hard code URIs, connection strings, access keys, or anything that application code needs to successfully communicate.
 
 These environment variables follow a naming convention that makes their use predictable. The naming pattern is derived from the connection name and resource type, which determines what values are required. This way the code that needs to read the values gets to define how they are named. Refer to the [reference documentation]({{< ref resource-schema >}}) of each resource for more information. 
 
-For example, adding a connection called `myconnection` that connects to a MongoDB resource would result in the following environment variables being injected:
+For example, adding a connection called `database` that connects to a MongoDB resource would result in the following environment variables being injected:
 
-```sh
-# the connection string to the resource
-CONNECTION_MYCONNECTION_CONNECTIONSTRING="mongodb://mongo:27017/mongo?authSource=admin"
-# Database name of the target resource
-CONNECTION_MYCONNECTION_DATABASE="my-database"
-# Username of the target resource
-CONNECTION_MYCONNECTION_USERNAME="admin"
-```
+| Key | Value |
+|-----|-------|
+| `CONNECTION_DATABASE_CONNECTIONSTRING` | The connection string to the database |
+| `CONNECTION_DATABASE_DATABASE` | Database name of the target database |
+| `CONNECTION_DATABASE_USERNAME` | Username of the target database |
+| `CONNECTION_DATABASE_PASSWORD` | Password of the target database |
 
 Alternatively, if you already have another convention you would like to follow or if you just prefer to be explicit, you may ignore the values generated by a connection and instead override it by setting your own environment variable values. Refer to the [environment variables how-to guide]({{< ref howto-environment-variables >}}) for more details.
 
-### Extensions
+## Extensions
 
 Extensions define additional capabilities and configuration for a container.
 
-#### Kubernetes metadata extension
+### Kubernetes metadata extension
 
 The [Kubernetes metadata extension]({{< ref kubernetes-metadata>}}) enables you to configure the Kubernetes metadata for the container. This includes the labels and annotations for the container. Refer to to the extension overview page to get more details about the extension and how it works with other Radius resources.
 
-#### Manual scaling extension
+### Manual scaling extension
 
 The manualScaling extension configures the number of replicas of a compute instance (such as a container) to run. Refer to the [container resource schema]({{< ref "container-schema#extensions" >}}) for more details.
 
-#### Dapr sidecar extension
+### Dapr sidecar extension
 
 The `daprSidecar` extensions adds and configures a [Dapr](https://dapr.io) sidecar to your application. Refer to the [container resource schema]({{< ref "container-schema#extensions" >}}) for more details
 
-## Resource schema 
-
-- [Container schema]({{< ref container-schema >}})
-
 ## Further reading
 
-{{< categorizeby category="How-To" tag="containers" >}}
+- [Container schema]({{< ref container-schema >}})

docs/content/reference/resource-schema/core-schema/container-schema/_index.md

@@ -28,6 +28,7 @@ weight: 300
 | [container](#container) | y | Container configuration. | [See below](#container)
 | [connections](#connections) | n | List of connections to other resources. | [See below](#connections)
 | [extensions](#extensions) | n | List of extensions on the container. | [See below](#extensions)
+| [runtimes](#runtimes) | n | Runtime specific configurations for the container. | [See below](#runtimes)
 
 ### Container
 
@@ -165,3 +166,15 @@ The `manualScaling` extension configures the number of replicas of a compute ins
 | kind | y | The kind of extension. | `manualScaling`
 | replicas | Y | The number of replicas to run | `5` |
 
+### Runtimes
+
+| Key  | Required | Description | Example |
+|------|:--------:|-------------|---------|
+| kubernetes | n | Kubernetes specific configuration for the container. | [See below](#kubernetes)
+
+#### Kubernetes
+
+| Key  | Required | Description | Example |
+|------|:--------:|-------------|---------|
+| base | n | The base Kubernetes resource manifest on top of which Radius specified properties will be applied. Supported resource types are documented [here]({{<ref "guides/author-apps/containers/overview#base-kubernetes-yaml">}}). | `loadTextContent('manifest/base-container.yaml')`
+| pod | n | The pod specifications to apply to the Kubernetes resource created by Radius. Any field defined on [PodSpec](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) can be set here. | [`topologySpreadConstraints`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling)

docs/content/reference/resource-schema/core-schema/container-schema/snippets/base-container.yaml

@@ -0,0 +1,19 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: frontend
+  labels:
+    app: frontend
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: frontend
+  template:
+    metadata:
+      labels:
+        app: frontend
+    spec:
+      containers:
+        - name: frontend
+          image: radiusdev.azurecr.io/magpie:latest

docs/content/reference/resource-schema/core-schema/container-schema/snippets/container.bicep

@@ -95,6 +95,20 @@ resource frontend 'Applications.Core/containers@2022-03-15-privatepreview' = {
         }
       }
     ]
+    runtimes: {
+      kubernetes: {
+        base: loadTextContent('base-container.yaml')
+        pod: {
+          containers: [
+            {
+              name: 'log-collector'
+              image: 'radiusdev.azurecr.io/fluent/fluent-bit:2.1.8'
+            }
+          ]
+          hostNetwork: true
+        }
+      }
+    }
   }
 }
 //CONTAINER