Skip to content

[installer] set the ServiceType as LB for ws-proxy #8759

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 29, 2022
Merged

[installer] set the ServiceType as LB for ws-proxy #8759

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion install/installer/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -163,12 +163,21 @@ yq eval-all --inplace \
gitpod.yaml
```

Similarly, if you are doing a `Workspace` only install (specifying `Workspace`
as the kind in config) you might want to change the service type of `ws-proxy` to `ClusterIP`
instead of the default `LoadBalancer`. You can post-process the YAML to change that.

```shell
yq eval-all --inplace \
'(select(.kind == "Service" and .metadata.name == "ws-proxy") | .spec.type) |= "ClusterIP"' \
gitpod.yaml
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Off-topic: Do we have already an issue to get rid of this post-processing step and having a config value for the service type?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@corneliusludmann there is no such issue open specifically for making the service type configurable. I guess the question is do we plan on making this configurable, since our thought process was to not make it configurable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm glad you brought that up. 🚀 Indeed, we decided like this in the past. However, 2 things have changed since then:

  • We introduced the experimental section. Everything that we won't support for some reason but need internally for SaaS should go there. We shouldn't need to rely on post-processing.
  • Since our official supported installation path will be the KOTS installation, we are a little more relaxed about the config surface.

What do you think, @mrsimonemms?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle, I'm happy for this to go into the experimental section. I think that should be a separate change though, as it will require discussion/agreement on the config surface change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the inactivity on this issue. I have created this issue to track this requirement. Shall we merge this PR and continue the work there?


## Error validating `StatefulSet.status`

```shell
error: error validating "gitpod.yaml": error validating data: ValidationError(StatefulSet.status): missing required field "availableReplicas" in io.k8s.api.apps.v1.StatefulSetStatus; if you choose to ignore these errors, turn validation off with --validate=false
```

Depending upon your Kubernetes implementation, you may receive this error. This is
due to a bug in the underlying StatefulSet dependency, which is used to generate the
OpenVSX proxy (see [#8529](https://github.com/gitpod-io/gitpod/issues/8529)).
Expand Down
49 changes: 31 additions & 18 deletions install/installer/pkg/components/ws-proxy/objects.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,9 @@ package wsproxy

import (
"github.com/gitpod-io/gitpod/installer/pkg/common"
"github.com/gitpod-io/gitpod/installer/pkg/config/v1"
corev1 "k8s.io/api/core/v1"
"k8s.io/apimachinery/pkg/runtime"
)

var Objects = common.CompositeRenderFunc(
Expand All @@ -14,23 +17,33 @@ var Objects = common.CompositeRenderFunc(
networkpolicy,
rolebinding,
role,
func(cfg *common.RenderContext) ([]runtime.Object, error) {
ports := map[string]common.ServicePort{
HTTPProxyPortName: {
ContainerPort: HTTPProxyPort,
ServicePort: HTTPProxyPort,
},
HTTPSProxyPortName: {
ContainerPort: HTTPSProxyPort,
ServicePort: HTTPSProxyPort,
},
MetricsPortName: {
ContainerPort: MetricsPort,
ServicePort: MetricsPort,
},
SSHPortName: {
ContainerPort: SSHTargetPort,
ServicePort: SSHServicePort,
},
}
return common.GenerateService(Component, ports, func(service *corev1.Service) {
// In the case of Workspace only setup, `ws-proxy` service is the entrypoint
// Hence we use LoadBalancer type for the service
if cfg.Config.Kind == config.InstallationWorkspace {
service.Spec.Type = corev1.ServiceTypeLoadBalancer
service.Annotations["cloud.google.com/neg"] = `{"exposed_ports": {"80":{},"443": {}}}`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to hardcode google specific annotations here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These annotations have been hardcoded for some time on the basis that a) they're ignored if not used and b) we don't really have an effective (and non-verbose) way of adding custom annotations to services. Elsewhere, there's also an annotation for external-dns with the same thinking

}
})(cfg)
},
common.DefaultServiceAccount(Component),
common.GenerateService(Component, map[string]common.ServicePort{
HTTPProxyPortName: {
ContainerPort: HTTPProxyPort,
ServicePort: HTTPProxyPort,
},
HTTPSProxyPortName: {
ContainerPort: HTTPSProxyPort,
ServicePort: HTTPSProxyPort,
},
MetricsPortName: {
ContainerPort: MetricsPort,
ServicePort: MetricsPort,
},
SSHPortName: {
ContainerPort: SSHTargetPort,
ServicePort: SSHServicePort,
},
}),
)