From ba6432debe678c831cc5b4db30a56e38ebb44f9a Mon Sep 17 00:00:00 2001 From: Juan Diego Palomino Date: Mon, 23 May 2022 07:58:51 -0700 Subject: [PATCH] Docs for new release (#191) * Docs for new release * fixing docs * typo * typo --- .../Reference/aws/modules/aws-k8s-service.md | 33 +++- .../aws/modules/cloudfront-distribution.md | 1 - .../en/Reference/aws/modules/helm-chart.md | 1 + .../azurerm/modules/azure-k8s-service.md | 33 +++- .../azurerm/modules/custom-terraform.md | 160 ++++++++++++++++++ .../Reference/azurerm/modules/helm-chart.md | 1 + .../google/modules/gcp-k8s-service.md | 35 +++- .../en/Reference/google/modules/helm-chart.md | 1 + 8 files changed, 244 insertions(+), 21 deletions(-) create mode 100644 content/en/Reference/azurerm/modules/custom-terraform.md diff --git a/content/en/Reference/aws/modules/aws-k8s-service.md b/content/en/Reference/aws/modules/aws-k8s-service.md index cef699c..f35659d 100644 --- a/content/en/Reference/aws/modules/aws-k8s-service.md +++ b/content/en/Reference/aws/modules/aws-k8s-service.md @@ -58,6 +58,23 @@ tl;dr An (optional) liveness probe determines whether your server should be rest be sent to a replica or be temporarily rerouted to other replicas. Essentially smart healthchecks. For websockets Opta just checks the tcp connection on the given port. +Opta supports 2 types of possible health checks (please be advised that while they're not required, they're highly +recommended): + +#### Option 1: Health Check HTTP Ping +Quite straightforward, K8s does regular http get requests to your server under a specific given path. +[Any code greater than or equal to 200 and less than 400 indicates success](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). +Any other code indicates failure. You can specify this by setting the `healthcheck_path` input, or alternatively the +`liveness_probe_path` and/or the `readiness_probe_path` if you want different behavior for the liveness and readiness +checks. + +#### Option 2: Health Check Command +Also simple to understand, K8s regularly execute a shell command of your choosing and considers the +server healthy if it has and exit code of 0. Commands should be passed in as a list of the different +parts (e.g. ["echo", "hello"]). You can specify this by setting the `healthcheck_command` input, or alternatively the +`liveness_probe_command` and/or the `readiness_probe_command` if you want different behavior for the liveness and +readiness checks. + ### Autoscaling As mentioned, autoscaling is available out of the box. We currently only support autoscaling @@ -209,16 +226,19 @@ Cron Jobs are currently created outside the default linkerd service mesh. | `autoscaling_target_mem_percentage` | See the [autoscaling](https://docs.opta.dev/reference/aws/modules/aws-k8s-service/#autoscaling) section. | `80` | False | | `secrets` | Deprecated, see [secrets instructions](/features/secrets). | `[]` | False | | `env_vars` | A map of key values to add to the container as environment variables (key is name, value is value). ```yaml env_vars: FLAG: "true" ``` | `[]` | False | -| `healthcheck_path` | See the See the [liveness/readiness](https://docs.opta.dev/reference/aws/modules/aws-k8s-service/#healthcheck-probe) section. Default `null` (i.e., no user-specified healthchecks) | `None` | False | -| `liveness_probe_path` | Use if liveness probe != readiness probe | `None` | False | -| `readiness_probe_path` | Use if liveness probe != readiness probe | `None` | False | +| `healthcheck_path` | See the See the [healthcheck probe](https://docs.opta.dev/reference/aws/modules/aws-k8s-service/#healthcheck-probe) section. Default `null` (i.e., no user-specified healthchecks) | `None` | False | +| `healthcheck_command` | See the See the [healthcheck probe](https://docs.opta.dev/reference/aws/modules/aws-k8s-service/#healthcheck-probe) section. Default `[]` (i.e., no user-specified healthchecks) | `[]` | False | +| `liveness_probe_command` | Use if using shell command liveness checks and liveness probe != readiness probe | `[]` | False | +| `readiness_probe_command` | Use if using shell command readiness checks and liveness probe != readiness probe | `[]` | False | +| `liveness_probe_path` | Use if using http ping liveness checks and liveness probe != readiness probe | `None` | False | +| `readiness_probe_path` | Use if using http ping readiness checks and liveness probe != readiness probe | `None` | False | | `initial_liveness_delay` | Use if the initial delay needs to be changed. | `30` | False | | `initial_readiness_delay` | Use if the initial delay needs to be changed. | `30` | False | | `consistent_hash` | Use [consistent hashing](https://www.nginx.com/resources/wiki/modules/consistent_hash/) | `None` | False | | `sticky_session` | Use [sticky sessions](https://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions) via cookies for your service (first request will send you a cookie called opta_cookie which you should add on future requests). | `False` | False | | `sticky_session_max_age` | If the sticky session is enabled, how long should the cookie last? | `86400` | False | -| `resource_request` | See the [resource requests](https://docs.opta.dev/reference/google/modules/gcp-k8s-service/#resource-requests) section. CPU is given in millicores, and Memory is in megabytes. | `{'cpu': 100, 'memory': 128}` | False | -| `resource_limits` | See the [resource limits]({{< relref "#resource-limits" >}}) section. Memory is in megabytes.. | `None` | False | +| `resource_request` | See the [container resources](https://docs.opta.dev/reference/aws/modules/aws-k8s-service/#resource-requests) section. CPU is given in millicores, and Memory is in megabytes. | `{'cpu': 100, 'memory': 128}` | False | +| `resource_limits` | See the [container resources]({{< relref "#resource-limits" >}}) section. Memory is in megabytes.. | `None` | False | | `public_uri` | The full domain to expose your app under as well as path prefix. Must be the full parent domain or a subdomain referencing the parent as such: "dummy.{parent[domain]}/my/path/prefix" | `[]` | False | | `keep_path_prefix` | Should we keep the prefix path which you set in the public uri when forwarding requests to your service? | `False` | False | | `additional_iam_policies` | A list of extra IAM role policies not captured by Opta which you wish to give to your service. | `[]` | False | @@ -227,7 +247,8 @@ Cron Jobs are currently created outside the default linkerd service mesh. | `ingress_extra_annotations` | These are extra annotations to add to ingress objects | `{}` | False | | `tolerations` | Taint tolerations to add to the pods. | `[]` | False | | `cron_jobs` | A list of cronjobs to execute as part of this service | `[]` | False | -| `pod_annotations` | These are extra annotations to add to k8s-service pod objects | `{}` | False | +| `pod_annotations` | These are extra annotations to add to k8s-service pod objects / replace defaults | `{}` | False | +| `pod_labels` | These are extra labels to add to k8s-service pod objects / replace defaults | `{}` | False | | `timeout` | Time in seconds to wait for deployment. | `300` | False | | `max_history` | The max amount of helm revisions to keep track of (0 for infinite) | `25` | False | diff --git a/content/en/Reference/aws/modules/cloudfront-distribution.md b/content/en/Reference/aws/modules/cloudfront-distribution.md index d41a76f..92aedca 100644 --- a/content/en/Reference/aws/modules/cloudfront-distribution.md +++ b/content/en/Reference/aws/modules/cloudfront-distribution.md @@ -52,7 +52,6 @@ modules: - type: k8s-cluster - type: k8s-base name: testbase - expose_self_signed_ssl: true - type: cloudfront-distribution links: - testbase diff --git a/content/en/Reference/aws/modules/helm-chart.md b/content/en/Reference/aws/modules/helm-chart.md index 1dc54d7..2459ac4 100644 --- a/content/en/Reference/aws/modules/helm-chart.md +++ b/content/en/Reference/aws/modules/helm-chart.md @@ -14,6 +14,7 @@ description: Plugs a custom helm chart into your Opta k8s cluster | Name | Description | Default | Required | | ----------- | ----------- | ------- | -------- | | `chart` | Name of the helm chart. Note that you don't need to use `/` - as repo is specified separately. Just do ``. If you're using a local chart, then this will be the path to the chart. | `None` | True | +| `release_name` | The name the chart installation is to have. | `None` | False | | `repository` | The helm repository to use (null means local chart) | `None` | False | | `namespace` | The kubernetes namespace to put the chart in | `default` | False | | `create_namespace` | Create namespace as well. | `False` | False | diff --git a/content/en/Reference/azurerm/modules/azure-k8s-service.md b/content/en/Reference/azurerm/modules/azure-k8s-service.md index 1b127cf..87776fd 100644 --- a/content/en/Reference/azurerm/modules/azure-k8s-service.md +++ b/content/en/Reference/azurerm/modules/azure-k8s-service.md @@ -57,6 +57,23 @@ tl;dr An (optional) liveness probe determines whether your server should be rest be sent to a replica or be temporarily rerouted to other replicas. Essentially smart healthchecks. For websockets Opta just checks the tcp connection on the given port. +Opta supports 2 types of possible health checks (please be advised that while they're not required, they're highly +recommended): + +#### Option 1: Health Check HTTP Ping +Quite straightforward, K8s does regular http get requests to your server under a specific given path. +[Any code greater than or equal to 200 and less than 400 indicates success](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). +Any other code indicates failure. You can specify this by setting the `healthcheck_path` input, or alternatively the +`liveness_probe_path` and/or the `readiness_probe_path` if you want different behavior for the liveness and readiness +checks. + +#### Option 2: Health Check Command +Also simple to understand, K8s regularly execute a shell command of your choosing and considers the +server healthy if it has and exit code of 0. Commands should be passed in as a list of the different +parts (e.g. ["echo", "hello"]). You can specify this by setting the `healthcheck_command` input, or alternatively the +`liveness_probe_command` and/or the `readiness_probe_command` if you want different behavior for the liveness and +readiness checks. + ### Autoscaling As mentioned, autoscaling is available out of the box. We currently only support autoscaling @@ -146,22 +163,26 @@ deleting the kubernetes persistent volume claims. | `autoscaling_target_mem_percentage` | See the [autoscaling](https://docs.opta.dev/reference/azurerm/modules/azure-k8s-service/#autoscaling) section. | `80` | False | | `secrets` | Deprecated, see [secrets instructions](/features/secrets). | `[]` | False | | `env_vars` | A map of key values to add to the container as environment variables (key is name, value is value). ```yaml env_vars: FLAG: "true" ``` | `[]` | False | -| `healthcheck_path` | See the See the [liveness/readiness](https://docs.opta.dev/reference/azurerm/modules/azure-k8s-service/#healthcheck-probe) section. Default `null` (i.e., no user-specified healthchecks) | `None` | False | -| `liveness_probe_path` | Use if liveness probe != readiness probe | `None` | False | -| `readiness_probe_path` | Use if liveness probe != readiness probe | `None` | False | +| `healthcheck_path` | See the See the [healthcheck probe](https://docs.opta.dev/reference/aws/modules/aws-k8s-service/#healthcheck-probe) section. Default `null` (i.e., no user-specified healthchecks) | `None` | False | +| `healthcheck_command` | See the See the [healthcheck probe](https://docs.opta.dev/reference/aws/modules/aws-k8s-service/#healthcheck-probe) section. Default `[]` (i.e., no user-specified healthchecks) | `[]` | False | +| `liveness_probe_command` | Use if using shell command liveness checks and liveness probe != readiness probe | `[]` | False | +| `readiness_probe_command` | Use if using shell command readiness checks and liveness probe != readiness probe | `[]` | False | +| `liveness_probe_path` | Use if using http ping liveness checks and liveness probe != readiness probe | `None` | False | +| `readiness_probe_path` | Use if using http ping readiness checks and liveness probe != readiness probe | `None` | False | | `initial_liveness_delay` | Use if the initial delay needs to be changed. | `30` | False | | `initial_readiness_delay` | Use if the initial delay needs to be changed. | `30` | False | | `consistent_hash` | Use [consistent hashing](https://www.nginx.com/resources/wiki/modules/consistent_hash/) | `None` | False | | `sticky_session` | Use [sticky sessions](https://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions) via cookies for your service (first request will send you a cookie called opta_cookie which you should add on future requests). | `False` | False | | `sticky_session_max_age` | If the sticky session is enabled, how long should the cookie last? | `86400` | False | -| `resource_request` | See the [resource requests](https://docs.opta.dev/reference/google/modules/gcp-k8s-service/#resource-requests) section. CPU is given in millicores, and Memory is in megabytes. | `{'cpu': 100, 'memory': 128}` | False | -| `resource_limits` | See the [resource limits]({{< relref "#resource-limits" >}}) section. Memory is in megabytes.. | `None` | False | +| `resource_request` | See the [container resources](https://docs.opta.dev/reference/azurerm/modules/azure-k8s-service/#resource-requests) section. CPU is given in millicores, and Memory is in megabytes. | `{'cpu': 100, 'memory': 128}` | False | +| `resource_limits` | See the [container resources]({{< relref "#resource-limits" >}}) section. Memory is in megabytes.. | `None` | False | | `public_uri` | The full domain to expose your app under as well as path prefix. Must be the full parent domain or a subdomain referencing the parent as such: "dummy.{parent[domain]}/my/path/prefix" | `[]` | False | | `keep_path_prefix` | Should we keep the prefix path which you set in the public uri when forwarding requests to your service? | `False` | False | | `links` | A list of extra IAM role policies not captured by Opta which you wish to give to your service. | `[]` | False | | `persistent_storage` | A list persistent storages to add to each instance of your service (need to give a `size` which is the size in GB for the storage volume to be, and `path` which is the path in the filesystem of each instance to place it under) | `[]` | False | | `ingress_extra_annotations` | These are extra annotations to add to ingress objects | `{}` | False | -| `pod_annotations` | These are extra annotations to add to k8s-service pod objects | `{}` | False | +| `pod_annotations` | These are extra annotations to add to k8s-service pod objects / replace defaults | `{}` | False | +| `pod_labels` | These are extra labels to add to k8s-service pod objects / replace defaults | `{}` | False | | `timeout` | Time in seconds to wait for deployment. | `300` | False | | `max_history` | The max amount of helm revisions to keep track of (0 for infinite) | `25` | False | diff --git a/content/en/Reference/azurerm/modules/custom-terraform.md b/content/en/Reference/azurerm/modules/custom-terraform.md new file mode 100644 index 0000000..8b31b7b --- /dev/null +++ b/content/en/Reference/azurerm/modules/custom-terraform.md @@ -0,0 +1,160 @@ +--- +title: "custom-terraform" +linkTitle: "custom-terraform" +date: 2021-12-7 +draft: false +weight: 1 +description: Allows user to bring in their own custom terraform module +--- + +This module allows a user to bring in their own custom terraform code into the opta ecosystem, to use in tandem with +their other opta modules, and even reference them. All a user needs to do is specify the +[source](https://www.terraform.io/language/modules/sources#module-sources) +to your module with the `source` input, and the desired inputs to your module (if any) via the +`terraform_inputs` input. + +## Use local terraform files +Suppose you have an opta azure environment written in `azure-env.yaml` and you want to deploy your custom terraform module +"blah" that creates something you want (in our case a vm instance). What you could do is create a service for your +environment which uses custom-terraform to call your module (NOTE: custom-terraform doesn't need to be in an opta +service-- it can be in the environment too). For our example, let's say that the file structure looks like so: + +``` +. +├── README.md +├── azure-env.yaml +└── dummy-service + ├── blah + │ └── main.tf + └── opta.yaml +``` + +The new service is written in `dummy-service/opta.yaml` and looks like this: + +```yaml +environments: + - name: azure-example + path: "../azure-env.yaml" +name: customtf +modules: + - type: custom-terraform + name: vm1 + source: "./blah" + terraform_inputs: + env_name: "{env}" +``` + +You can see that the path to your module is specified by `source` (you can use relative or absolute paths), +as are the expected inputs `hello` and `subnet_self_link`. Note that you can use opta interpolation to use variables or +the outputs of the parent environment or other modules as input. + +Lastly, you can use the following as content to the main.tf file of the blah module to complete the example/demo: + +```hcl +variable "env_name" { + type = string +} + +variable "prefix" { + type = string + default = "placeholder" +} + +data "azurerm_resource_group" "opta" { + name = "opta-${var.env_name}" +} + +data "azurerm_subnet" "opta" { + name = "opta-${var.env_name}-subnet" + virtual_network_name = "opta-${var.env_name}" + resource_group_name = data.azurerm_resource_group.opta.name +} + +resource "azurerm_network_interface" "main" { + name = "${var.prefix}-nic" + location = data.azurerm_resource_group.opta.location + resource_group_name = data.azurerm_resource_group.opta.name + + ip_configuration { + name = "testconfiguration1" + subnet_id = data.azurerm_subnet.opta.id + private_ip_address_allocation = "Dynamic" + } +} + +resource "azurerm_virtual_machine" "main" { + name = "${var.prefix}-vm" + location = data.azurerm_resource_group.opta.location + resource_group_name = data.azurerm_resource_group.opta.name + network_interface_ids = [azurerm_network_interface.main.id] + vm_size = "Standard_DS1_v2" + + storage_image_reference { + publisher = "Canonical" + offer = "UbuntuServer" + sku = "16.04-LTS" + version = "latest" + } + storage_os_disk { + name = "myosdisk1" + caching = "ReadWrite" + create_option = "FromImage" + managed_disk_type = "Standard_LRS" + } + os_profile { + computer_name = "hostname" + admin_username = "testadmin" + admin_password = "Password1234!" + } + os_profile_linux_config { + disable_password_authentication = false + } + tags = { + environment = "staging" + } +} +``` + +Once you opta apply the service you should see your new compute instance up and running in the Azure console and be able +to ssh into it. + +## Use a remote terraform module +The `source` input uses terraform's [module source](https://www.terraform.io/language/modules/sources#module-sources) +logic behind the scenes and so follows the same format/limitations. Thus, you can use this for locally available modules, +or modules available remotely.Z + +**WARNING** Be very, very, careful about what remote modules you are using, as they leave you wide open to supply chain +attacks, depending on the security and character of the owner of said module. It's highly advised to use either +[official modules](https://registry.terraform.io/browse/modules) or modules under your company's control. + +## Using Outputs from your Custom Terraform Module +Currently you can use outputs of your custom terraform module in the same yaml, like so: +```yaml +environments: + - name: azure-example + path: "../azure-env.yaml" +name: customtf +modules: + - type: custom-terraform + name: hi1 + source: "./blah1" # <-- This module has an output called output1 + - type: custom-terraform + name: hi2 + source: "./blah2" + terraform_inputs: + input1: "${{module.hi1.output1}}" # <-- HERE. Note the ${{}} wrapping +``` + +These outputs, however, currently can not be used in other yamls (e.g. if you put custom terraform in an environment +yaml its outputs can't be used in the services), and will not show up in the `opta output` command. Work on supporting +this is ongoing. + +## Fields + + +| Name | Description | Default | Required | +| ----------- | ----------- | ------- | -------- | +| `source` | The source of your terraform module. For more info, check out https://www.terraform.io/language/modules/sources#module-sources | `None` | False | +| `path_to_module` | Deprecated, use source | `None` | False | +| `version` | The version of the remote module to use. For more info, check out https://www.terraform.io/language/modules/syntax#version | `None` | False | +| `terraform_inputs` | The variables which you wish to pass into your custom module. | `{}` | False | \ No newline at end of file diff --git a/content/en/Reference/azurerm/modules/helm-chart.md b/content/en/Reference/azurerm/modules/helm-chart.md index 1dc54d7..2459ac4 100644 --- a/content/en/Reference/azurerm/modules/helm-chart.md +++ b/content/en/Reference/azurerm/modules/helm-chart.md @@ -14,6 +14,7 @@ description: Plugs a custom helm chart into your Opta k8s cluster | Name | Description | Default | Required | | ----------- | ----------- | ------- | -------- | | `chart` | Name of the helm chart. Note that you don't need to use `/` - as repo is specified separately. Just do ``. If you're using a local chart, then this will be the path to the chart. | `None` | True | +| `release_name` | The name the chart installation is to have. | `None` | False | | `repository` | The helm repository to use (null means local chart) | `None` | False | | `namespace` | The kubernetes namespace to put the chart in | `default` | False | | `create_namespace` | Create namespace as well. | `False` | False | diff --git a/content/en/Reference/google/modules/gcp-k8s-service.md b/content/en/Reference/google/modules/gcp-k8s-service.md index 3686098..a0fd43b 100644 --- a/content/en/Reference/google/modules/gcp-k8s-service.md +++ b/content/en/Reference/google/modules/gcp-k8s-service.md @@ -58,6 +58,23 @@ tl;dr An (optional) liveness probe determines whether your server should be rest be sent to a replica or be temporarily rerouted to other replicas. Essentially smart healthchecks. For websockets Opta just checks the tcp connection on the given port. +Opta supports 2 types of possible health checks (please be advised that while they're not required, they're highly +recommended): + +#### Option 1: Health Check HTTP Ping +Quite straightforward, K8s does regular http get requests to your server under a specific given path. +[Any code greater than or equal to 200 and less than 400 indicates success](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). +Any other code indicates failure. You can specify this by setting the `healthcheck_path` input, or alternatively the +`liveness_probe_path` and/or the `readiness_probe_path` if you want different behavior for the liveness and readiness +checks. + +#### Option 2: Health Check Command +Also simple to understand, K8s regularly execute a shell command of your choosing and considers the +server healthy if it has and exit code of 0. Commands should be passed in as a list of the different +parts (e.g. ["echo", "hello"]). You can specify this by setting the `healthcheck_command` input, or alternatively the +`liveness_probe_command` and/or the `readiness_probe_command` if you want different behavior for the liveness and +readiness checks. + ### Autoscaling As mentioned, autoscaling is available out of the box. We currently only support autoscaling @@ -208,16 +225,17 @@ Cron Jobs are currently created outside the default linkerd service mesh. | `autoscaling_target_mem_percentage` | See the [autoscaling](https://docs.opta.dev/reference/google/modules/gcp-k8s-service/#autoscaling) section. | `80` | False | | `secrets` | Deprecated, see [secrets instructions](/features/secrets). | `[]` | False | | `env_vars` | A map of key values to add to the container as environment variables (key is name, value is value). ```yaml env_vars: FLAG: "true" ``` | `[]` | False | -| `healthcheck_path` | See the See the [liveness/readiness](https://docs.opta.dev/reference/google/modules/gcp-k8s-service/#healthcheck-probe) section. Default `null` (i.e., no user-specified healthchecks) | `None` | False | -| `liveness_probe_path` | Use if liveness probe != readiness probe | `None` | False | -| `readiness_probe_path` | Use if liveness probe != readiness probe | `None` | False | -| `initial_liveness_delay` | Use if the initial delay needs to be changed. | `30` | False | -| `initial_readiness_delay` | Use if the initial delay needs to be changed. | `30` | False | +| `healthcheck_path` | See the See the [healthcheck probe](https://docs.opta.dev/reference/aws/modules/aws-k8s-service/#healthcheck-probe) section. Default `null` (i.e., no user-specified healthchecks) | `None` | False | +| `healthcheck_command` | See the See the [healthcheck probe](https://docs.opta.dev/reference/aws/modules/aws-k8s-service/#healthcheck-probe) section. Default `[]` (i.e., no user-specified healthchecks) | `[]` | False | +| `liveness_probe_command` | Use if using shell command liveness checks and liveness probe != readiness probe | `[]` | False | +| `readiness_probe_command` | Use if using shell command readiness checks and liveness probe != readiness probe | `[]` | False | +| `liveness_probe_path` | Use if using http ping liveness checks and liveness probe != readiness probe | `None` | False | +| `readiness_probe_path` | Use if using http ping readiness checks and liveness probe != readiness probe | `None` | False | | `consistent_hash` | Use [consistent hashing](https://www.nginx.com/resources/wiki/modules/consistent_hash/) | `None` | False | | `sticky_session` | Use [sticky sessions](https://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions) via cookies for your service (first request will send you a cookie called opta_cookie which you should add on future requests). | `False` | False | | `sticky_session_max_age` | If the sticky session is enabled, how long should the cookie last? | `86400` | False | -| `resource_request` | See the [resource requests](https://docs.opta.dev/reference/google/modules/gcp-k8s-service/#resource-requests) section. CPU is given in millicores, and Memory is in megabytes. | `{'cpu': 100, 'memory': 128}` | False | -| `resource_limits` | See the [resource limits]({{< relref "#resource-limits" >}}) section. Memory is in megabytes.. | `None` | False | +| `resource_request` | See the [container resources](https://docs.opta.dev/reference/google/modules/gcp-k8s-service/#resource-requests) section. CPU is given in millicores, and Memory is in megabytes. | `{'cpu': 100, 'memory': 128}` | False | +| `resource_limits` | See the [container resources](https://docs.opta.dev/reference/google/modules/gcp-k8s-service/#resource-limits) section. Memory is in megabytes.. | `None` | False | | `public_uri` | The full domain to expose your app under as well as path prefix. Must be the full parent domain or a subdomain referencing the parent as such: "dummy.{parent[domain]}/my/path/prefix" | `[]` | False | | `keep_path_prefix` | Should we keep the prefix path which you set in the public uri when forwarding requests to your service? | `False` | False | | `links` | A list of extra IAM role policies not captured by Opta which you wish to give to your service. | `[]` | False | @@ -226,7 +244,8 @@ Cron Jobs are currently created outside the default linkerd service mesh. | `additional_iam_roles` | A list of extra project-level iam roles to grant to the service account created for this k8s service | `[]` | False | | `tolerations` | Taint tolerations to add to the pods. | `[]` | False | | `cron_jobs` | A list of cronjobs to execute as part of this service | `[]` | False | -| `pod_annotations` | These are extra annotations to add to k8s-service pod objects | `{}` | False | +| `pod_annotations` | These are extra annotations to add to k8s-service pod objects / replace defaults | `{}` | False | +| `pod_labels` | These are extra labels to add to k8s-service pod objects / replace defaults | `{}` | False | | `timeout` | Time in seconds to wait for deployment. | `300` | False | | `max_history` | The max amount of helm revisions to keep track of (0 for infinite) | `25` | False | diff --git a/content/en/Reference/google/modules/helm-chart.md b/content/en/Reference/google/modules/helm-chart.md index 1dc54d7..2459ac4 100644 --- a/content/en/Reference/google/modules/helm-chart.md +++ b/content/en/Reference/google/modules/helm-chart.md @@ -14,6 +14,7 @@ description: Plugs a custom helm chart into your Opta k8s cluster | Name | Description | Default | Required | | ----------- | ----------- | ------- | -------- | | `chart` | Name of the helm chart. Note that you don't need to use `/` - as repo is specified separately. Just do ``. If you're using a local chart, then this will be the path to the chart. | `None` | True | +| `release_name` | The name the chart installation is to have. | `None` | False | | `repository` | The helm repository to use (null means local chart) | `None` | False | | `namespace` | The kubernetes namespace to put the chart in | `default` | False | | `create_namespace` | Create namespace as well. | `False` | False |