summaryrefslogtreecommitdiff
path: root/doc/development/kubernetes.md
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2019-09-18 18:06:14 +0000
committerGitLab Bot <gitlab-bot@gitlab.com>2019-09-18 18:06:14 +0000
commitb08279013423a66f06f5edde4e067f328fe135bd (patch)
tree47aca1a9b0655cd7861bddf31ec17d4b302fc4ea /doc/development/kubernetes.md
parent4584eb0e07d372d6014de16ab359965475184c99 (diff)
downloadgitlab-ce-b08279013423a66f06f5edde4e067f328fe135bd.tar.gz
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/development/kubernetes.md')
-rw-r--r--doc/development/kubernetes.md12
1 files changed, 6 insertions, 6 deletions
diff --git a/doc/development/kubernetes.md b/doc/development/kubernetes.md
index 5265e5b11cd..5443bdea043 100644
--- a/doc/development/kubernetes.md
+++ b/doc/development/kubernetes.md
@@ -29,12 +29,12 @@ We use the [`kubeclient`](https://rubygems.org/gems/kubeclient) gem to
perform Kubernetes API calls. As the `kubeclient` gem does not support
different API Groups (e.g. `apis/rbac.authorization.k8s.io`) from a
single client, we have created a wrapper class,
-[`Gitlab::Kubernetes::KubeClient`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/kubernetes/kube_client.rb)
+[`Gitlab::Kubernetes::KubeClient`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/kubernetes/kube_client.rb)
that will enable you to achieve this.
Selected Kubernetes API groups are currently supported. Do add support
for new API groups or methods to
-[`Gitlab::Kubernetes::KubeClient`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/kubernetes/kube_client.rb)
+[`Gitlab::Kubernetes::KubeClient`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/kubernetes/kube_client.rb)
if you need to use them. New API groups or API group versions can be
added to `SUPPORTED_API_GROUPS` - internally, this will create an
internal client for that group. New methods can be added as a delegation
@@ -54,7 +54,7 @@ worker](sidekiq_style_guide.md).
There are instances where you would like to make calls to Kubernetes and
return the response and as such a background worker does not seem to be
a good fit. For such cases you should make use of [reactive
-caching](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/models/concerns/reactive_caching.rb).
+caching](https://gitlab.com/gitlab-org/gitlab/blob/master/app/models/concerns/reactive_caching.rb).
For example:
```ruby
@@ -72,7 +72,7 @@ For example:
### Testing
We have some Webmock stubs in
-[`KubernetesHelpers`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/support/helpers/kubernetes_helpers.rb)
+[`KubernetesHelpers`](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/support/helpers/kubernetes_helpers.rb)
which can help with mocking out calls to Kubernetes API in your tests.
## Security
@@ -87,7 +87,7 @@ a cluster.
Mitigation strategies include:
1. Not allowing redirects to attacker controller resources:
- [`Kubeclient::KubeClient`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/kubernetes/kube_client.rb#)
+ [`Kubeclient::KubeClient`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/kubernetes/kube_client.rb#)
can be configured to disallow any redirects by passing in
`http_max_redirects: 0` as an option.
1. Not exposing error messages: by doing so, we
@@ -111,7 +111,7 @@ Logs related to the Kubernetes integration can be found in
GDK install, this will be present in `log/kubernetes.log`.
Some services such as
-[`Clusters::Applications::InstallService`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/services/clusters/applications/install_service.rb#L18)
+[`Clusters::Applications::InstallService`](https://gitlab.com/gitlab-org/gitlab/blob/master/app/services/clusters/applications/install_service.rb#L18)
rescues `StandardError` which can make it harder to debug issues in an
development environment. The current workaround is to temporarily
comment out the `rescue` in your local development source.