746dacc47c
- Add e2e tests
- Use '=' for traffic and tag assignment instead of ':'
- Use --tag and --untag flags for tagging traffic targets
- Use --traffic flag for setting traffic portions
- Allow --traffic portion to either take revisionName or tagName
- Uses @latest identifier for referencing latest revision of service
- Dont throw error if requested revision=tag pair is same
- Support having multiple tags for a revision
- creates a new target in traffic block if revision present in traffic block with new tag requested
- creates N new targets in traffic block if revision absent in traffic block with Nxnew tags requested
- Ensure updating tag of @latest requires --untag flag
- streamline updating tag for latestReadyRevision
- adds respective tests
- adds tests for ensuring given traffic sum to 100 on CLI and fail fast
- Add note about preference of order in case where tagOfOneRevision == revisionOfAnother,
first tags are checked and assigned traffic if any, as tags are supposed to be
unique in traffic block and should be referenced in such scenario.
- Remove the examples from flag description, moves it to service update command example section
- Pass only traffic block to compute trffic, makes it better to consume.
- Cover more error cases for invalid value format for assignments, covers a=b=c, a=, =b, or variants of them
- Separate and improves the error messages
- Add unit tests for traffic computing
- Add sanity checks in dedicated function verifyInputSanity
- traffic perents should sum to 100
- individual percent should be in 0-100
- repetition of @latest or tagName or revisionRef is disallowed
- Verify traffic percents sum to 100 on client side and fail fast
- Add e2e tests for traffic splitting
- create and update service, assign tags and set traffic to make an existing state
- run the scenario on existing state of service
- form the desired state traffic block
- extract the traffic block and form the traffic block struct actual state
- assert.DeepEqual actual and desired traffic blocks
- Use logic to generate service name in the same way as namespace, use different service name per test case
- Run e2e test for traffic splitting in parallel
- Use timeout duration of 30m for e2e tests, use timeout parameter for go_test_e2e library function
- Use tagName in flag description of --untag, avoiding conflict with --tag flag
- Update CHANGELOG
|
||
|---|---|---|
| .. | ||
| cmd | ||
| README.md | ||
| plugins.md | ||
| workflows.md | ||
README.md
kn
kn is the Knative command line interface (CLI).
Getting Started
Installing kn
You can grab the latest nightly binary executable for:
Put it on your system path, and make sure it's executable.
Alternatively, check out the client repository, and type:
go install ./cmd/kn
Connecting to your cluster
You'll need a kubectl-style config file to connect to your cluster.
- Starting minikube writes this file (or gives you an appropriate context in an existing config file)
- Instructions for Google GKE
- Instructions for Amazon EKS
- Instructions for IBM IKS
- Instructions for Red Hat OpenShift.
- Or contact your cluster administrator.
kn will pick up your kubectl config file in the default location of
$HOME/.kube/config. You can specify an alternate kubeconfig connection file
with --kubeconfig, or the env var $KUBECONFIG, for any command.
Commands
See the generated documentation
Service Management
A Knative service is the embodiment of a serverless workload. It is generally in the form of a collection of containers running in a group of pods, in the underlying Kubernetes cluster. Each Knative service associates with a collection of revisions, which represent the evolution of that service.
With the Kn CLI a user can list, create, delete, and update Knative services. The detail reference of each sub-command under the service command shows the options and flags for this group of commands.
Examples:
# Create a new service from an image
kn service create mysvc --env KEY1=VALUE1 --env KEY2=VALUE2 --image dev.local/ns/image:latest
You are able to also specify the requests and limits of both CPU and memory when creating a service. See service create command reference for additional details.
# List existing services in the 'default' namespace of your cluster
kn service list
You can also list services from all namespaces or a specific namespace using flags: --all-namespaces and --namespace mynamespace. See service list command reference for additional details.
Revision Management
A Knative revision is a "snapshot" of the specification of a service. For instance, when a Knative service is created with the environment variable FOO=bar a revision is added to the service. Afterwards, when the environment variable is changed to baz or additional variables are added, a new revision is created. When the image that the service is running is changed to a new digest, a new revision is created.
With the revision command group you can list and describe the current revisions on a service.
Examples:
# Listing a service's revision
kn revision list --service srvc # CHECK this since current command does not have --service flag
Utilities
These are commands that provide some useful information to the user.
- The
kn helpcommand displays a list of the commands with helpful information. - The
kn versioncommand will display the current version of theknbuild including date and Git commit revision. - The
kn completioncommand will output a BASH completion script forknto allow command completions with tabs.
Common Flags
For every Kn command you can use these optional common additional flags:
-hor--helpto display specific help for that command--config stringwhich specifies the Kn config file (default is $HOME/.kn.yaml)--kubeconfig stringwhich specifies the kubectl config file (default is $HOME/.kube/config)