Rachael L. Graham: Merge pull request #4412 from alchemy-containers/r…

…lg-nlb

cs_access_reference.md

@@ -124,16 +124,16 @@ The following table shows the permissions granted by each {{site.data.keyword.cl
 | Delete a log filtering configuration. | [`ibmcloud ks logging filter rm`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_log_filter_delete) | [`DELETE /v1/logging/{idOrName}/filterconfigs/{id}`](https://containers.cloud.ibm.com/global/swagger-global-api/#/filter/DeleteFilterConfig) |
 | Delete all logging filter configurations for the Kubernetes cluster. | - | [`DELETE /v1/logging/{idOrName}/filterconfigs`](https://containers.cloud.ibm.com/global/swagger-global-api/#/filter/DeleteFilterConfigs) |
 | Update a log filtering configuration. | [`ibmcloud ks logging filter update`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_log_filter_update) | [`PUT /v1/logging/{idOrName}/filterconfigs/{id}`](https://containers.cloud.ibm.com/global/swagger-global-api/#/filter/UpdateFilterConfig) |
-| Add one NLB IP address to an existing NLB host name. | [`ibmcloud ks nlb-dns add`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-add) | [`PUT /clusters/{idOrName}/add`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-dns/UpdateDNSWithIP) |
-| Create a DNS host name to register an NLB IP address. | [`ibmcloud ks nlb-dns create`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-create) | [`POST /clusters/{idOrName}/register`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-dns/RegisterDNSWithIP) |
-| List the NLB host names and IP addresses that are registered in a cluster. | [`ibmcloud ks nlb-dns ls`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-ls) | [`GET /clusters/{idOrName}/list`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-dns/ListNLBIPsForSubdomain) |
-| Remove an NLB IP address from a host name. | [`ibmcloud ks nlb-dns rm`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-rm) | [`DELETE /clusters/{idOrName}/host/{nlbHost}/ip/{nlbIP}/remove`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-dns/UnregisterDNSWithIP) |
-| Configure and optionally enable a health check monitor for an existing NLB host name in a cluster. | [`ibmcloud ks nlb-dns monitor configure`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-monitor-configure) | [`POST /health/clusters/{idOrName}/config`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-health-monitor/AddNlbDNSHealthMonitor) |
+| Add one NLB IP address to an existing NLB subdomain. | [`ibmcloud ks nlb-dns add`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-add) | [`PUT /clusters/{idOrName}/add`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-dns/UpdateDNSWithIP) |
+| Create a DNS subdomain to register an NLB IP address. | [`ibmcloud ks nlb-dns create`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-create) | [`POST /clusters/{idOrName}/register`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-dns/RegisterDNSWithIP) |
+| List the NLB subdomains and IP addresses that are registered in a cluster. | [`ibmcloud ks nlb-dns ls`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-ls) | [`GET /clusters/{idOrName}/list`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-dns/ListNLBIPsForSubdomain) |
+| Remove an NLB IP address from a subdomain. | [`ibmcloud ks nlb-dns rm`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-rm) | [`DELETE /clusters/{idOrName}/host/{nlbHost}/ip/{nlbIP}/remove`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-dns/UnregisterDNSWithIP) |
+| Configure and optionally enable a health check monitor for an existing NLB subdomain in a cluster. | [`ibmcloud ks nlb-dns monitor configure`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-monitor-configure) | [`POST /health/clusters/{idOrName}/config`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-health-monitor/AddNlbDNSHealthMonitor) |
 | View the settings for an existing health check monitor. | [`ibmcloud ks nlb-dns monitor get`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-monitor-get) | [`GET /health/clusters/{idOrName}/host/{nlbHost}/config`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-health-monitor/GetNlbDNSHealthMonitor) |
-| Disable an existing health check monitor for a host name in a cluster. | [`ibmcloud ks nlb-dns monitor disable`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-monitor-disable) | [`PUT /clusters/{idOrName}/health`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-health-monitor/UpdateNlbDNSHealthMonitor) |
+| Disable an existing health check monitor for a subdomain in a cluster. | [`ibmcloud ks nlb-dns monitor disable`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-monitor-disable) | [`PUT /clusters/{idOrName}/health`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-health-monitor/UpdateNlbDNSHealthMonitor) |
 | Enable a health check monitor that you configured. | [`ibmcloud ks nlb-dns monitor enable`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-monitor-enable) | [`PUT /clusters/{idOrName}/health`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-health-monitor/UpdateNlbDNSHealthMonitor) |
-| List the health check monitor settings for each NLB host name in a cluster. | [`ibmcloud ks nlb-dns monitor ls`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-monitor-ls) | [`GET /health/clusters/{idOrName}/list`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-health-monitor/ListNlbDNSHealthMonitors) |
-| List the health check status of each IP address that is registered with an NLB host name in a cluster. | [`ibmcloud ks nlb-dns monitor status`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-monitor-status) | [`GET /health/clusters/{idOrName}/status`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-health-monitor/ListNlbDNSHealthMonitorStatus) |
+| List the health check monitor settings for each NLB subdomain in a cluster. | [`ibmcloud ks nlb-dns monitor ls`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-monitor-ls) | [`GET /health/clusters/{idOrName}/list`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-health-monitor/ListNlbDNSHealthMonitors) |
+| List the health check status of each IP address that is registered with an NLB subdomain in a cluster. | [`ibmcloud ks nlb-dns monitor status`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-monitor-status) | [`GET /health/clusters/{idOrName}/status`](https://containers.cloud.ibm.com/global/swagger-global-api/#/nlb-health-monitor/ListNlbDNSHealthMonitorStatus) |
 | Create a webhook in a cluster. | [`ibmcloud ks webhook-create`](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_webhook_create) | [`POST /v1/clusters/{idOrName}/webhooks`](https://containers.cloud.ibm.com/global/swagger-global-api/#/clusters/AddClusterWebhooks) |
 {: class="simple-tab-table"}
 {: caption="Overview of permissions required for CLI commands and API calls in {{site.data.keyword.containerlong_notm}}." caption-side="top"}

cs_app_knative.md

@@ -2,7 +2,7 @@
 
 copyright:
   years: 2014, 2019
-lastupdated: "2019-09-03"
+lastupdated: "2019-09-05"
 
 keywords: kubernetes, iks, knative
 
@@ -250,16 +250,16 @@ After you set up Knative in your cluster, you can deploy your serverless app as
 {: shortdesc}
 
 **What is a Knative service?** </br>
-To deploy an app with Knative, you must specify a Knative `Service` resource. A Knative service is managed by the Knative `Serving` primitive and is responsible to manage the entire lifecycle of the workload. When you create the service, the Knative `Serving` primitive automatically creates a version for your serverless app and adds this version to the revision history of the service. Your serverless app is assigned a public URL from your Ingress subdomain in the format `<knative_service_name>-<namespace>.<ingress_subdomain>` that you can use to access the app from the internet. In addition, a private host name is assigned to your app in the format `<knative_service_name>-<namespace>.cluster.local` that you can use to access your app from within the cluster.
+To deploy an app with Knative, you must specify a Knative `Service` resource. A Knative service is managed by the Knative `Serving` primitive and is responsible to manage the entire lifecycle of the workload. When you create the service, the Knative `Serving` primitive automatically creates a version for your serverless app and adds this version to the revision history of the service. Your serverless app is assigned a public URL from your Ingress subdomain in the format `<knative_service_name>-<namespace>.<ingress_subdomain>` that you can use to access the app from the internet. In addition, a private hostname is assigned to your app in the format `<knative_service_name>-<namespace>.cluster.local` that you can use to access your app from within the cluster.
 
 **What happens behind the scenes when I create the Knative service?**</br>
-When you create a Knative service, your app is automatically deployed as a Kubernetes pod in your cluster and exposed by using a Kubernetes service. To assign the public host name, Knative uses the IBM-provided Ingress subdomain and TLS certificate. Incoming network traffic is routed based on the default IBM-provided Ingress routing rules.
+When you create a Knative service, your app is automatically deployed as a Kubernetes pod in your cluster and exposed by using a Kubernetes service. To assign the public hostname, Knative uses the IBM-provided Ingress subdomain and TLS certificate. Incoming network traffic is routed based on the default IBM-provided Ingress routing rules.
 
 **How can I roll out a new version of my app?**</br>
-When you update your Knative service, a new version of your serverless app is created. This version is assigned the same public and private host names as your previous version. By default, all incoming network traffic is routed to the latest version of your app. However, you can also specify the percentage of incoming network traffic that you want to route to a specific app version so that you can do A-B testing. You can split incoming network traffic between two app versions at a time, the current version of your app and the new version that you want to roll over to.  
+When you update your Knative service, a new version of your serverless app is created. This version is assigned the same public and private hostnames as your previous version. By default, all incoming network traffic is routed to the latest version of your app. However, you can also specify the percentage of incoming network traffic that you want to route to a specific app version so that you can do A-B testing. You can split incoming network traffic between two app versions at a time, the current version of your app and the new version that you want to roll over to.  
 
 **Can I bring my own custom domain and TLS certificate?** </br>
-You can change the configmap of your Istio Ingress gateway and the Ingress routing rules to use your custom domain name and TLS certificate when you assign a host name to your serverless app. For more information, see [Setting up custom domain names and certificates](#knative-custom-domain-tls).
+You can change the configmap of your Istio Ingress gateway and the Ingress routing rules to use your custom domain name and TLS certificate when you assign a hostname to your serverless app. For more information, see [Setting up custom domain names and certificates](#knative-custom-domain-tls).
 
 To deploy your serverless app as a Knative service:
 
@@ -457,10 +457,10 @@ To deploy your serverless app as a Knative service:
 ## Setting up custom domain names and certificates
 {: #knative-custom-domain-tls}
 
-You can configure Knative to assign host names from your own custom domain that you configured with TLS.
+You can configure Knative to assign hostnames from your own custom domain that you configured with TLS.
 {: shortdesc}
 
-By default, every app is assigned a public subdomain from your Ingress subdomain in the format `<knative_service_name>-<namespace>.<ingress_subdomain>` that you can use to access the app from the Internet. In addition, a private host name is assigned to your app in the format `<knative_service_name>-<namespace>.cluster.local` that you can use to access your app from within the cluster. If you want to assign host names from a custom domain that you own, you can change the Knative configmap to use the custom domain instead.
+By default, every app is assigned a public subdomain from your Ingress subdomain in the format `<knative_service_name>-<namespace>.<ingress_subdomain>` that you can use to access the app from the Internet. In addition, a private hostname is assigned to your app in the format `<knative_service_name>-<namespace>.cluster.local` that you can use to access your app from within the cluster. If you want to assign hostnames from a custom domain that you own, you can change the Knative configmap to use the custom domain instead.
 
 1. Create a custom domain. To register your custom domain, work with your Domain Name Service (DNS) provider or [IBM Cloud DNS](/docs/infrastructure/dns?topic=dns-getting-started).
 2. Configure your domain to route incoming network traffic to the IBM-provided Ingress gateway. Choose between these options:
@@ -535,15 +535,15 @@ By default, every app is assigned a public subdomain from your Ingress subdomain
    The `spec.rules.host` and `spec.tls.hosts` sections are lists and can include multiple custom domains and TLS certificates.
    {: tip}
 
-7. Modify the Knative `config-domain` configmap to use your custom domain to assign host names to new Knative services.
+7. Modify the Knative `config-domain` configmap to use your custom domain to assign hostnames to new Knative services.
    1. Open the `config-domain` configmap to start editing it.
       ```
       kubectl edit configmap config-domain -n knative-serving
       ```
       {: pre}
 
    2. Specify your custom domain in the `data` section of your configmap and remove the default domain that is set for your cluster.
-      - **Example to assign a host name from your custom domain for all Knative services**:
+      - **Example to assign a hostname from your custom domain for all Knative services**:
         ```
         apiVersion: v1
         kind: ConfigMap
@@ -555,9 +555,9 @@ By default, every app is assigned a public subdomain from your Ingress subdomain
         ```
         {: codeblock}
 
-        By adding `""` to your custom domain, all Knative services that you create are assigned a host name from your custom domain.  
+        By adding `""` to your custom domain, all Knative services that you create are assigned a hostname from your custom domain.  
 
-      - **Example to assign a host name from your custom domain for select Knative services**:
+      - **Example to assign a hostname from your custom domain for select Knative services**:
         ```
         apiVersion: v1
         kind: ConfigMap
@@ -572,7 +572,7 @@ By default, every app is assigned a public subdomain from your Ingress subdomain
         ```
         {: codeblock}
 
-        To assign a host name from your custom domain for select Knative services only, add a `data.selector` label key and value to your configmap. In this example, all services with the label `app: sample` are assigned a host name from your custom domain. Make sure to also have a domain name that you want to assign to all other apps that do not have the `app: sample` label. In this example, the default IBM-provided domain `mycluster.us-south.containers.appdomain.cloud` is used.
+        To assign a hostname from your custom domain for select Knative services only, add a `data.selector` label key and value to your configmap. In this example, all services with the label `app: sample` are assigned a hostname from your custom domain. Make sure to also have a domain name that you want to assign to all other apps that do not have the `app: sample` label. In this example, the default IBM-provided domain `mycluster.us-south.containers.appdomain.cloud` is used.
     3. Save your changes.
 
 With your Ingress routing rules and Knative configmaps all set up, you can create Knative services with your custom domain and TLS certificate.
@@ -950,7 +950,7 @@ If you do not want Knative to scale down your service to zero instances, set the
 ### Creating private-only serverless apps
 {: #knative-private-only}
 
-By default, every Knative service is assigned a public route from your Istio Ingress subdomain and a private route in the format `<service_name>.<namespace>.cluster.local`. You can use the public route to access your app from the public network. If you want to keep your service private, you can add the `serving.knative.dev/visibility` label to your Knative service. This label instructs Knative to assign a private host name to your service only.
+By default, every Knative service is assigned a public route from your Istio Ingress subdomain and a private route in the format `<service_name>.<namespace>.cluster.local`. You can use the public route to access your app from the public network. If you want to keep your service private, you can add the `serving.knative.dev/visibility` label to your Knative service. This label instructs Knative to assign a private hostname to your service only.
 {: shortdesc}
 
 ```
@@ -977,7 +977,7 @@ spec:
 <tbody>
 <tr>
 <td><code>serving.knative.dev/visibility</code></td>
-  <td>If you add the <code>serving.knative.dev/visibility: cluster-local</code> label, your service is assigned only a private route in the format <code>&lt;service_name&gt;.&lt;namespace&gt;.cluster.local</code>. You can use the private host name to access your service from within the cluster, but you cannot access your service from the public network.  </td>
+  <td>If you add the <code>serving.knative.dev/visibility: cluster-local</code> label, your service is assigned only a private route in the format <code>&lt;service_name&gt;.&lt;namespace&gt;.cluster.local</code>. You can use the private hostname to access your service from within the cluster, but you cannot access your service from the public network.  </td>
 </tr>
 </tbody>
 </table>

cs_cli_changelog.md

@@ -2,7 +2,7 @@
 
 copyright:
   years: 2014, 2019
-lastupdated: "2019-09-04"
+lastupdated: "2019-09-05"
 
 keywords: kubernetes, iks
 
@@ -163,7 +163,7 @@ Refer to the following table for a summary of changes for each {{site.data.keywo
 <tr>
 <td>0.2.102</td>
 <td>15 Apr 2019</td>
-<td>Adds the [`ibmcloud ks nlb-dns` group of commands](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#nlb-dns) for registering and managing a host name for network load balancer (NLB) IP addresses, and the [`ibmcloud ks nlb-dns monitor` group of commands](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-monitor-configure) for creating and modifying health check monitors for NLB host names. For more information, see [Registering NLB IPs with a DNS host name](/docs/containers?topic=containers-loadbalancer_hostname#loadbalancer_hostname_dns).
+<td>Adds the [`ibmcloud ks nlb-dns` group of commands](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#nlb-dns) for registering and managing a subdomain for network load balancer (NLB) IP addresses, and the [`ibmcloud ks nlb-dns monitor` group of commands](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_nlb-dns-monitor-configure) for creating and modifying health check monitors for NLB subdomains. For more information, see [Registering NLB IPs with a DNS subdomain](/docs/containers?topic=containers-loadbalancer_hostname#loadbalancer_hostname_dns).
 </td>
 </tr>
 <tr>